I'm looking forward to having integers in Javascript.
The dart2js numerics divergence isn't a problem in practice, as during testing/development the Dart VM is run with a flag which throws if an integer escapes the 2^53 safe range. And if an integer is overflowing to a double in production code then this is a bug anyway.
It would be nice if Javascript VM's could also provide a similar feature, at least until bignums land. But I guess this is difficult as there is no way to distinguish which numbers are intended to be integers and which are actually doubles.
after first asking someone to cite such a problem.
AFAICT the "isn't a problem in practice" happy-talk is all coming from Dart insiders. Does this shoe fit?
Anyway, it's a real Dart bug that drives potential users away. And why is JS bignum support -- which Google for-sure could have championed in Ecma TC39 and prototype-implemented in V8 -- just an "It would be nice" thing?
(It is not difficult to support suffixes for new value types, e.g. 0m for decimal and 0n or better for bignum. This is on the ES7 agenda. For more on range analysis and other/better optimization options, see https://news.ycombinator.com/item?id=6950475.)
Trusting checked-mode test coverage is bold in light of this bug, where bold might be "stupid" or "you're fired". As I wrote once in this thread already, Murphy was an optimist.
I agree this needs to be fixed in JS. And I have been following the ES strawmen/proposals. Not sure if I like suffixes. The approach in Dart seems to work well too.
In JS the overflow is often silent and is easy to miss. Since the DartVM can throw an exception on overflow this makes it easier to catch. So the Dart toolchain is an improvement, but also not ideal.
Where correctness is important there are also 32/64bit and bignum libraries which can be compiled to js but are slow.
http://code.google.com/p/dart/issues/detail?id=1533
Could be addressed via asm.js bignum emulation and should be addressed by work (w/ Googlers helping) on bignums in ES-next.