Hacker News Reader

Comment by floitsch | Hacker News Reader

That's not really the problem. Web developers have learned from the past and don't just build web-pages for one browser only. On the contrary... Developers now sometimes need to support outdated browsers with little market share (IE8 for example), instead of actively pushing the users to upgrade.

The discrepancy between Dart and JS numbers is mostly an issue for the developers. When they deal with numbers in specific ranges, they need to run dart2js more frequently (to test if their code works) instead of relying on Dartium (and its F5 development cycle).

After 2 years of Dart development, numbers have rarely been an issue in practice. Developers know when they deal with numbers > 32/53bits and work around it.

View on HN

> Web developers have learned from the past and don't just build web-pages for one browser only.

This is not true in practice. Just a few days ago I couldn't use clippercard.com on Firefox for Android because the WebKit prefixes broke the design so badly as to be unusable. :(

For numerous other examples: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=evangel...

> When they deal with numbers in specific ranges, they need to run dart2js more frequently (to test if their code works) instead of relying on Dartium (and its F5 development cycle).

And if they don't, their pages lock their users into Chrome…

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.

/be

You must realize how different the situations are between Java BigIntegers and Dart integers.

Please, inform me, if you are not trolling on the cheap.

https://www.dartlang.org/articles/numeric-computation/

http://docs.oracle.com/javase/7/docs/api/java/math/BigIntege...

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.

/be

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.

http://mraleph.tumblr.com/post/24351748336/explaining-js-vm-...

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

http://rfrn.org/~shu/drafts/ti.pdf‎

This avoids most of those checks that you assume are too expensive (and by assuming, so casually fork Dart semantics).

Here is a JS version of [Hackett&Shu, PLDI 2012], from @pcwalton:

https://github.com/pcwalton/doctorjsmm/

Can the full JIT+TI approach to bignum/double/int perform well enough for dart2js? Better find out, because forking semantics is just the wrong thing.

Another road not taken: we hear "can't wait for JS to get better", but Dart started at least by 2010, possibly earlier.

http://wiki.ecmascript.org/doku.php?id=strawman:bignums

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?

/be

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.

/be

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)

/be

Reply on news.ycombinator.com