@voidstar Note: I've got a fair bit of experience programming in C and C++ in desktop and embedded environments, high level and low level, so I understand exactly what you're saying here... yet I'm not really bothered by it. Perhaps they could create an opaque object type for it...

@thor Quite likely it is, but with Node being increasingly used for regular apps (see Atom, with a wide install base, where this could be highly relevant) I think this is actually something they should fix. And since they expose it, it's not something bolted on, they should have dealt with it when they first created that ability.

@voidstar How would they implement it properly, exactly? There's no 64-bit integer type in JS. If node stored this number in 64-bit form, they'd be forced to cast it to double almost immediately, because all the rest of their code is probably designed around that. It actually seems like a genuinely tricky problem to solve. Maybe they could use a two-element UInt32Array...

@voidstar node.js is from 2009 and UInt32Array, the only data type that could conceivably handle this somewhat cleanly, was only standardized in 2015. Betcha the node.js FS implementation is much older than 2015.

@thor Node.js has the capability of using native code, they could write portable C to handle it internally. As an exposed interface, yea probably UInt32[2] but ideally everything needing >53-bit integers (or numbers) could use native code. Like some kind of native generic "bignum" library this uses. 64-bit integers in native code have been around longer than UInt32.

@thor And if you want to allow Node without native code, make it optional and have the functions spew warnings about possible integer truncation if they aren't backed by native code.