“We have decided not to integrate the Dart VM into Chrome”

You wrote "The same is actually happening to the unique features of Dart such as typing and SIMD and better modules." My reply: no, yes (thanks to bottom-up work by John McCutchan, not "Dart people" plural -- there you go again), and nope. Any types for ES7/2016 or beyond are likely to be based on TypeScript, Flow, and V8's SoundScript experiment, not on Dart. Modules in ES6 have no relation to Dart modules/packages.

Really, "exaggeration" doesn't being to capture the false overreach of your first comment, and walking back from it to vague "everything's influencing JS" isn't helping.

Apart from SIMD, Google by investing in Dart at cost to JS (recreated V8 team; replace-not-embrace strategy for ~5 years) missed out on uplifting ES6 to have bignums and other things that would materially aid correctness and performance of dart2js, which is now the only way forward for Dart in browsers.

I hate playing Cassandra, but the good news is that Troy didn't fall: JS prevailed, at some unnecessary cost, and as predicted. See https://news.ycombinator.com/item?id=2982949 et seq.

Sorry, using the present tense for things that will be in browsers years later (hopefully) is a common practice that's an issue with me. Let's stick with what people can actually use today.

Also, pointing to features people can use in different dialects of JavaScript is not really fair. Just about everything you can think of has been experimented with and probably deployed somewhere. It doesn't count unless it's all available in the same toolchain and can be used in a unified way while writing a single app.

What are optical types? I've never heard of this term and Google turned up nothing on it.

I don't think that the premise ("given there are so many superior options") is a non-controversial assertion. Which is probably why people who reject it would (and have been) picking it as a compile-to-JS language for web-facing projects.

The focus on compile-to-JS and JS interop for the web announced in the blog post makes Dart a more, rather than less, attractive language for web development, because it eases fears that taking full advantage of Dart might, in the near future, mean "works better on Chrome" rather than "targets the whole web", and because it means that Dart will work better with the universe of browser-targeted tools that aren't all written in Dart.

The VM is crossplatform and it even supports ARM and MIPS.

They are also working on an interpreter which will get around the JIT restrictions on iOS and Windows Phone.

As far as I can tell, the Dart team set out to create a clean slate approach to what web developers need in a language (front-end and on the server) to address today's complexities. What the Dart team couldn't foresee how many developers would come down with Stockholm syndrome regarding JavaScript.

What people don’t get: adding more crap to JavaScript doesn’t make things easier, it makes things more complex. Think about it: the entire web is depending on a language that was thrown together in like 10 days and renamed from LiveScript to it would contain the word 'Java' because Java was the new hotness back in the day even though it had nothing to do with Jsva.

And now we’re going to add all of the stuff we didn't think about back then when JavaScript was considered a weird, fringe toy language, when the most complex thing anyone did was image rollovers.

JavaScript didn't "win" because it was great; it won because it good enough and we were literally stuck with it.

Not everyone wants good enough; some people want an excellent, purpose built language for the web with all of the goodies we’ve come to expect on Day 1--no polyfills, no hacks, no waiting for a years long standards process to run its course.

I’m looking forward to the Dart conference next month to see what’s next: https://www.dartlang.org/events/2015/summit/.

If there are so many, can you list at least 5 superior options for us please.

I'm probably going to sound very negative in saying this, but I _really_ hate it when people pull this line out like it means anything. Only in the most narrow, trite sense is a programming language "just a tool." They are the whole reason programmers exist. Language is the single most important development in human history, and computers have touched human life in irreversible and undeniably important ways.

Everything is just a tool, if you look at it the right way, and it takes a particular kind of pointlessness to opt to see the world like that.

Language is the thing that makes the genie grant your wish. If you wish with the wrong words, you get a billion dollar tombstone.

Unless it turns out that JS+Flow is actually the best balance between flexibility and safety and the world will reach "singularity".

So I take it you write all your *nix programs in C?

So you think JavaScript is the best tool for the job? I don't think so.

https://twitter.com/BrendanEich/status/308343704194781186

SIMD is in all the SoCs of course, which means it has been on JS stewards' radar for a while now (remember River Trail? see my blog post, which had early Dart humor and Dash-memo reaction: https://brendaneich.com/2011/09/capitoljs-rivertrail/).

I worked at MicroUnity from 1992-5 on many high-risk things including a new CPU that was designed to do extensive SIMD and bit-moving instructions; using these in an instruction-level simulator, I implemented 64-QAM demod and Reed-Solomon error correction for the cable-net of the day (TCL, remember them?). Alas the CPU design was unrealizable in hardware.

SIMD has been around quite a while in hardware, so as KGadd says intrinsics for it have shown up in major languages. It was only a matter of time and the right person for JS, and John McCutchan did the job. Thanks, John!

Google funded John's work for Dart and didn't keep him from doing JS uplift, so thanks to Google too.

Improving the web, in particular, requires that people think like maintainers and innovators.

Not necessarily! That next abstraction may enable you to simplify your implementation, carving out lower layers of abstraction cruft.

It may be possible to compile pieces of a Dart program that don't need GC (think pure numeric computation stuff) to use asm.js and use the full JS language for the rest, but I don't know if anyone's seriously looked at doing that.

Evolution can fill gaps in JS, and has: typed arrays are one example; generators another. More to do, but it's not as if the distance x cost to suffer in filling gaps is greater than the distance x cost of doing a de-novo VM among all browsers, on top of keeping JS going. It's much, much less.

LLVM is simply not a good starting point for the problem here, nice as LLVM is for what it does do well.

A million lines of code is relatively small when you're trying to be all things to all ads customers in the world.

Still, could it be simpler? I hope so.

If it doesn't serve ads it doesn't release cool open source projects no self driving cars, no Anjular JS, no google maps, gmail and so on.

This, alas, falls under the "nothing to publicly announce" umbrella.

> The Dart blog post was unclear about the future of the Dart VM.

The VM team is still moving full speed ahead. In some ways, their job is easier now because they don't have to worry about the (considerable) complexity of integrating the VM into a very large application that already has another language VM, GC, very large set of API bindings (the DOM), etc.

IMO it is much better to focus on improving compile-to-web support with things like bytecode, better debugging, threading, custom value types, hooks into the garbage collector, etc., etc. - making it feel more like "compilation", less like "transpilation" (to the extent the term implies that you have to look at the output) - than to change the number of blessed languages from one to two. The result, if used to compile Dart (or any other language), might sacrifice a bit of performance compared to the maximum achievable by a dedicated Dart VM, but not that much, and there are myriad advantages.

I'd recommend instead a comment like: "Consider $otheroption, it has $feature1, $feature2, and $feature3. Furthermore, it is entirely committed to $designprincipal, which provides complete safety against $classofmistake when used correctly, without any $kindofdownside."

This way your reader has something to engage with other than your emotional reaction, and they may have learned something along the way.

  class Month {
    static const List<String> names = const <String>[
      "JAN", "FEB", "MAR", "APR", "MAY", "JUN", 
      "JUL", "AUG", "SEP", "OCT", "NOV", "DEC"                                                    
    ];
    final int month;
    const Month(this.month);
    MonthDay operator -(int day) => new MonthDay(month, day);
    String toString() => names[month - 1];
  }

  class MonthDay {
    final int month;
    final int day;
    MonthDay(this.month, this.day);
    DateTime operator -(int year) => new DateTime(year, month, day);
    String toString() => "${Month.names[month - 1]}-${"$day".padLeft(2, "0")}";
  }

  const Month JAN = const Month(1);
  const Month FEB = const Month(2);
  const Month MAR = const Month(3);
  const Month APR = const Month(4);
  const Month MAY = const Month(5);
  const Month JUN = const Month(6);
  const Month JUL = const Month(7);
  const Month AUG = const Month(8);
  const Month SEP = const Month(9);
  const Month OCT = const Month(10);
  const Month NOV = const Month(11);
  const Month DEC = const Month(12);

  main() {
    print(MAR-25-2015);
  }

  new Date(Heisei, 27, 1, 1)

The problem is not with parameter ordering. Year and day are literal, month is zero indexed. So you wind up with (month -1) representing the actual month.

That's easy to specify, but is it good for the user? You've just opened the door to memory leaks on my machine in poorly-written "javascript".

But where was the "bad for everyone" when Google rolled SPDY into Chrome and its own services, and showed not only tangible improvements to HTTP/1.1 but also an actual conviction in its efforts? It took a few years, but there was a good amount of industry momentum behind SPDY even before its ordainment as HTTP/2 became certain.

All Dart ever got was a Chromium fork; how was it ever meant to make inroads without Google putting any wood behind it?

Dart tools: pub's (package manager) client, analyzer, dart2js compiler, etc are all written in Dart.

We have a good story for server side developement and we are not looking to abandon it but rather we are looking to expand it, e.g. we just released a package to facilitate creation of REST APIs[1]. Pub's server side is being rewritten into Dart as we speak[2]

Among cool internal users of Dart VM I could mention Google Fiber - they'll share their experience during the upcoming Dart Summit[3].

[1] http://news.dartlang.org/2015/03/create-your-own-rest-api-wi...

[2] https://github.com/dart-lang/pub-dartlang-dart

[3] https://www.dartlang.org/events/2015/summit/sessions/google-...