Web developers know too well the trap of testing only on one browser, which when Dart comes to Chrome, will be Chrome. Testing all input data in a space that exceeds the integral ___domain of double is hard. Murphy says there will be bugs in other browsers when one's app tests "work in Chrome".
For a wannabe-cross-browser, wannabe-standard (Ecma has a sorry history of proprietary standards: C#, OOXML) language pushed by a super-rich big company with what? 60 or more engineers on the project, optics must matter. Why not fix the bignum-not-emulated-in-JS bug? It's easy, GWT has BigInteger emulation code in JS lying around the Googleplex. Just plug that in if the code needs it.
The obvious risk remains what I cited in HN two years ago: Google letting dart2js be sub-standard, using all its strength and leverage to promote Dart in combination with DartVM, letting users of other browsers "blame their browser" when things don't quite work as well as in Chrome.
Given market share among browsers currently, I think this will backfire, but it could inflict collateral damage too -- on developers as well as on users. And it just plain looks bad. People expect better of Google, and they ought to.
Both arbitrary precision immutable integer types. If some corner case differs, my point stands. Google has more than enough engineers on Dart to do the work of writing a bignum library in JS, if they can't find one to use that someone already wrote.
I'm definitely not trolling. I truly thought you would understand the basic difference.
Big integer support in Dart is not an issue of writing a bignum library. That's already been done. The difficulty is in supporting the single integer type in a way that's performant for numbers < 2^53
Java has fixed width ints, Dart has infinite precision ints. In Java when dealing with ints, you're always in the int ___domain, and when dealing with BigIntegers you're always in the BigInteger ___domain. In Java operations on ints can overflow. In Dart operations on ints don't overflow - internally, if the result doesn't fit in an machine int a bigint is returned.
In JavaScript you have a few choices when implementing infinite precision ints: 1) Use a single bigint type for all ints, which will be incredibly slow. 2) Use two types for ints, the built-in number and a BigInteger class. This means a lot of expensive type and overflow checks that slow down basic numeric operations. 3) Don't implement infinite precision ints.
Compile-to-JS languages can use static analysis to do better. dart2js already uses type inferencing extensively to eliminate type checks where it can, but eliminating the checks for ints would require range propagation which is much trickier, and doesn't work in a lot of cases.
> dart2js already uses type inferencing extensively to eliminate type checks where it can, but eliminating the checks for ints would require range propagation which is much trickier, and doesn't work in a lot of cases.
Couldn't you just have changed Dart to fix the semantics?
This is a big issue (no pun intended) that essentially means that dart2js is broken. I predict that, absent some solution to this issue, if Dart takes off, there will be sites that break in non-Chrome browsers when (for example) 64 bit hashing algorithms are involved due to authors only testing in Chrome and not testing the dart2js version.
"I truly thought" you would not raise a question to which V8/Dart people already know the answer. Range prop is not the only solution.
Use JIT techniques to speculate profitably that most ints fit in JS doubles. This can be done in JS-hosted VMs, just as in machine-code-generating native VMs.
Again, this is extremely old hat to the Dart/V8 folks. See, e.g.
In SpiderMonkey, we augment JIT techniques with online type inference that distinguishes int from double. The same type inference could add bignum to the speculative tower. See
could have been proposed and actually worked into ES6 by now, but the Dart team was in stealth mode (Dash) for too long. Still, better late than never. There's time for ES7. Who from Google will actually do the work in V8 and with Ecma TC39?
This is sounding less and less like just plugging GWTs BigInteger implementation into Dart, which is exactly my point when I said you must know the difference.
Using a GWT BigInteger for all dart2js integers would work just fine and provide correct semantics, but if it doesn't meet their performance bar, that's a failure of design - not an excuse for cutting corners and shipping a dart2js that produces wrong behavior.
This could have been accounted for with a better language design, but it wasn't.
Could have been accounted for in language design, dart2js effort, bignums-for-JS effort, or some combination of the last two. I don't want to assume a conclusion, but the lack of a fix for http://code.google.com/p/dart/issues/detail?id=1533 is a problem, even if there's no immediate fix. It is fixable.
No, you changed the argument from correctness to performance.
Makes me wonder if the problem is not entitled sloth with a dash of anti-JS animus, rather: wholesale, '90s-Microsoft-style-lock-in, submarine-the-other-browsers dirty pool.
Of course, if dart2js produced too-slow-JS, that might limit Dart adoption. Not a dilemma, given a good-faith effort to optimize per my comment above -- and much better than forking the language between DartVM and dart2js, leaving a trap for the unwary Dart programmer to fall into when using dart2js to run on all the non-DartVM browsers.
"Make it correct, then make it fast." Is this no longer done where you work? (Which would be Google, amirite? :-P)
For a wannabe-cross-browser, wannabe-standard (Ecma has a sorry history of proprietary standards: C#, OOXML) language pushed by a super-rich big company with what? 60 or more engineers on the project, optics must matter. Why not fix the bignum-not-emulated-in-JS bug? It's easy, GWT has BigInteger emulation code in JS lying around the Googleplex. Just plug that in if the code needs it.
The obvious risk remains what I cited in HN two years ago: Google letting dart2js be sub-standard, using all its strength and leverage to promote Dart in combination with DartVM, letting users of other browsers "blame their browser" when things don't quite work as well as in Chrome.
Given market share among browsers currently, I think this will backfire, but it could inflict collateral damage too -- on developers as well as on users. And it just plain looks bad. People expect better of Google, and they ought to.
/be