Hacker News Reader

Comment by cwyers | Hacker News Reader

Dart was basically Google's CoffeeScript, a compile-to-JS language that was supposed to sand off JavaScript's rough edges while still running in any web browser with JavaScript support. It didn't catch on, and one of the reasons is that this is right around the time when CoffeeScript started to fall out of favor, JavaScript got a lot of new features that alleviated enough of the pain points that people didn't want to deal with debugging code that was compiled into JavaScript, and stuff like Emscripten and TypeScript moved into the space. So it feels like the state of JavaScript has moved on by where Dart was, it still have enough JavaScript influence that the JavaScript haters don't really want to touch it, it's not enough like JavaScript for JavaScript enthusiasts to really like it, and there's no community around it so if you want to work in it and Google hasn't provided a library or framework that does what you want you need to roll your own.

View on HN

> Dart was basically Google's CoffeeScript, a compile-to-JS language that was supposed to sand off JavaScript's rough edges while still running in any web browser with JavaScript support.

Actually (and this is ultimately the reason for a lot of the political resistance), Dart was imagined as a replacement for JS, with an in-browser Dart VM as the ultimate preferred target for front end. Dart2JS was overtly a bridge until other browser vendors signed on by adopting the DartVM or implementing their own. (It was used even for Chrome, because Google wanted to avoid Chrome-only or “runs better in Chrome” Dart code on the public web, but that was insufficient to quell political resistance.)

Yes but it means that much of Dart was designed around the limitations inherent in JS, which means you get stupid stuff like the int primitive being: "Integer values, which generally should be in the range -2^53 to 2^53" https://www.dartlang.org/guides/language/language-tour#numbe...

Or a completely lack of parallelism, which is an omission that grows ever larger as even mobile SoCs are flirting with double-digit CPU cores.

So you got all the downsides of JS with none of the community/libraries of JS and with performance promises that only manifested with a custom build of Chrome. That's not a happy place to end up.

If they hard-kill dart2js then maybe Dart could turn into a nice language, but dart2js is what keeps Dart from becoming interesting. But since it looks like Dart 2 is going to still support the web via dart2js it doesn't look like Dart's going to get any more compelling.

> Yes but it means that much of Dart was designed around the limitations inherent in JS, which means you get stupid stuff like the int primitive being: "Integer values, which generally should be in the range -2^53 to 2^53"

As your own reference notes, Dart ints are defined as arbitrary precision, but dart2js uses js numbers (IEEE 754 doubles), so it's outside the listed range are problematic with code thst might be deployed via dart2js; it has no issues on Dart VM.

> Or a completely lack of parallelism

Dart’s concurrency model offers shared-nothing parallelism on Dart VM; it doesn't have shared-memory parallelism, which is limiting for some used, but it's not a complete lack of parallelism.

> As your own reference notes, Dart ints are defined as arbitrary precision, but dart2js uses js numbers (IEEE 754 doubles), so it's outside the listed range are problematic with code thst might be deployed via dart2js; it has no issues on Dart VM.

Yes, but it's now a quirk of Dart which is the problem. The behavior of your basic int primitive is dependent on the VM it's running in, that's a pretty bad language design decision.

> Dart’s concurrency model offers shared-nothing parallelism on Dart VM; it doesn't have shared-memory parallelism, which is limiting for some used, but it's not a complete lack of parallelism.

It's the same as JS+WebWorkers which is enough to claim a checkmark in the parallelism feature box without actually supporting anyone's use case (although JS+WebWorkers almost had shared memory which would have helped a little until meltdown/spectre happened). Since all communication goes through an extremely expensive pipe and all objects are serialized & copied it doesn't even work well in a shared-nothing context, which really needs to be able to move things to work well. That barely lets you do basic thread offloading in narrow circumstances when data passing needs are very small, to say nothing of using parallelism to speed something up.

> The behavior of your basic int primitive is dependent on the VM it's running in, that's a pretty bad language design decision.

What would you do instead? Any choice other than the underlying platform's native number type will significantly negatively impact performance and make interop much harder.

It doesn't matter how much nicer your preferred number type is, if you make "a + b" or "getNumberFromPlatform()" slow, your users aren't going to be happy.

Scala.js uses JS numbers for Byte, Int, Float, and Double (though it implements correct overflow for operations on fixed-size number types).

Kotlin.js does the same.

TypeScript uses JS numbers and has no integer type at all.

Elm says ints are 32 bits, but uses JS numbers to represent them.

You do what all those examples you just listed do, you say int is 32-bit which fits in JavaScript number just fine.

Then for longs you either don't support them or suck it up and pay the manual cost, which is what kotlin.js does.

Only dart did this crazy nonsense of an int type that is 2^53 sometimes and has methods like isNaN() on it.

> you say int is 32-bit which fits in JavaScript number just fine.

32 bits isn't actually enough for many uses today. Lists with more than 2^32 elements are not unheard of. File offsets larger than that are certainly a thing.

Dart only has a single integer type, so restricting it to 32 bits would restrict all users of integers to that size.

> Only dart did this crazy nonsense of an int type that is 2^53 sometimes and has methods like isNaN() on it.

isNan() is a method on num, which is the supertype of int and double, where it makes sense. (I don't know why they didn't define it just on double.)

> Lists with more than 2^32 elements are not unheard of.

In the use cases Dart targets yes, yes they are. They are extremely unheard of.

BUT even if they aren't, you can't use those from dart2js anyway. JS arrays are limited to uint32 lengths:

"Every Array object has a length property whose value is always a nonnegative integer less than 2^32"

https://www.ecma-international.org/ecma-262/5.1/#sec-15.4

Now sure you could make your own list type that lets you index to 2^53 in Dart, but you're into custom list territory now and math operations on a 64-bit long being a bit slower than native is unlikely to be relevant. You're probably not using flat indexing at that point anyway.

File offsets actually highlights the perfect problem with dart's approach. 2^53 isn't enough to interop with file systems using uint64s, as node.js discovered when trying to use JS Number for inodes ( https://github.com/nodejs/node/issues/12115 ) So things that actually need large numbers don't work anyway.

> In the use cases Dart targets yes, yes they are. They are extremely unheard of.

Dart is a general purpose language it wasn't intended to be web front-end only.

> File offsets actually highlights the perfect problem with dart's approach. 2^53 isn't enough to interop with file systems using uint64

Dart ints aren't limited to 2^53 except when using dart2js. It's an arbitrary size type, otherwise. Anyplace it would need to deal with inodes, the dart2js limit wouldn't be a problem.

> isNan() is a method on num, which is the supertype of int and double, where it makes sense. (I don't know why they didn't define it just on double.)

Because it allows more general code to apply isNaN to nums generally, and always be false for ints (or potential future subtypes that likewise can't be NaN), even leaving aside JavaScript environment questions.

But dart supports static typing, so that's just awkward. What does it even mean to take a num? What do you do with a generic num that may or may not be a double where isNaN makes sense? What value does this even have in a world of only int & double anyway? If a function returns 'num' does that mean isNaN is now something I need to worry about, or is it just badly over-generic code and it meant 'int'?

Stepping back, though, methods like isNaN only apply to a specialized subset of numbers, not the base on which all numbers build off of. So putting it on the base number class is the wrong layering. Same reason that bitwise operators are on int instead of num, because they don't apply to all numbers.

dart2js is a very small sliver of what Dart is.

The original Dart announcement was a presentation entitled "Dart: A Structured Web Programming Language." Dart has evolved beyond that mostly by necessity; people weren't adopting it for web programming, and so if it was going to survive, it needed to adapt.

http://gotocon.com/dl/goto-aarhus-2011/slides/GiladBracha_an...

Right, but that legacy isn't a great reason to hate on what Dart is now

Programming languages have killer apps that define how people engage with them. Perl was "instead of using shell scripts with sed/awk you can use a 'real' programming language." Java was "here's C without so many footguns." C# was "here's Java without having to deal with Sun/Oracle." Dart was supposed to have a killer app around web development and didn't make it. Even something like Flutter has incremental improvements over stuff like React Native, Xamarin Forms and other cross-platform UI toolkits. There's still no killer app there.

Reply on news.ycombinator.com