These situations can sometimes happen by accident or for technical reasons. And for me the web is far too important to take the risk.
> Dart has all the perils of an embrace and extinguish situation even if it is not the intention.
I'm not sure what you mean by "perils" here, but if it's just "by deciding to use a product, you could end up following it in a bad direction if they do that", I'm not sure how that's different from any other product. Any technology can go in unpredicted directions.
> Developers commit to Dart only to find in the future that the DartVM/Dart2JS targets have differing behavior or levels of attention.
Historically, the dart2js team has had as many or more resources than the VM team. If you consider the past a predictor of the future, then this shouldn't be a concern.
> And then suddenly Dart apps require Chrome and we end up with same IE6 mess again.
That would be pretty crazy of us, though, right? We want our language to be successful. Intentionally making it only work on a minority of browsers (and the unbelievably massive negative political repercussions of doing that) wouldn't exactly do much for Dart's adoption.
I'm trying to imagine some nefarious scenario where that could happen, and I'm having trouble conjuring one up.
Evil Chrome exec: Well done, minion! Dart is successful and has
lots of users! Now is our chance to attack!
Evil Dart exec: What have you in mind, O Master?
Evil Chrome exec: Now we'll add a feature to Dart that only the
VM supports. Users will have to use Chrome in order to run apps
that use that feature! Mua-hahahaha!
Evil Dart exec: But master, why would a developer use that feature
if they know it will prevent millions of users from running their
app?
Evil Chrome exec: Uh... it will be such a delightful feature they
won't be able to resist. Like... I don't know, currying or
something.
Evil Dart exec: But what happens if someone just sends us a patch
to implement it dart2js too?
Evil Chrome exec: Well, don't land it, obviously!
Evil Dart exec: What should we say in the code review?
Evil Chrome exec: Why do you bother me with these details? Just
move ahead with our plan!
Evil Dart exec: Remind me again what our plan is master?
Evil Chrome exec: To force the world to use Chrome! Soon, we will
be as successful as IE6 was!
Evil Dart exec: Not to question your wisdom, master, but IE is no
longer the dominant browser, so that didn't work out well for
them, did it?
Also, developers now universally revile IE because of their
practices. We'd be shunned if we did something like that.Edit: Consider this dummy example:
f(a, b) { return a + b; }
With operator overloading, the compiler has to account for that, and must transpile to e.g. function f(a, b) { return __invokePlus(a, b); }
Unless the programmer adds type hints f(num a, num b) { return a + b; }
Edit: mraleph told me that I'm incorrect - apparently the transpiler does global type inference on the code and will only generate a function call if the type needs it (or if it can't figure out the type)Exactly right. We need to do that, or numeric code would be impossibly slow when compiled to JS.