Shared publicly  - 
Hello ECMA-408, the new official Dart Programming Language Specification!

Download it here:

+Gilad Bracha writes:

ECMA formally approved the Dart language specification just a few days ago.

We just had the third meeting of ECMA TC52, the Dart standards committee.
We discussed enums, deferred loading, async, and minor bug fixes to the existing spec. 

We decided not to vote on deferred loading, even though that is pretty much done, and rather deal with all proposed changes to the freshly minted spec later in the year. Our next meeting is in Switzerland on September 16th. The goal is to formally incorporate enums and deferred loading, and at least a subset of the async proposal, in the next rev of the spec, which we hope to get done by the end of 2014.

Bear in mind that deferred loading is shipping; the existing spec allows experimentation on that.

Wrt to enums, I will publish a revised draft proposal soon. Differences vs. the last draft are very minor.

As for async - we are working on an article to explain our plans. Since that is taking a bit longer, I want to explain where we are in a separate mail later today.

Seth Ladd's profile photoWilliam Slatton's profile photoTanguy Krotoff's profile photoJeremy Bell's profile photo
Dart to be renamed ECMALang
Awesome news.. the sooner we get rid of Javascript the better.
+William Slatton It really is bad. It's liked by some because it's loose (weak/dynamicly typed) but the prototypal inheritance/__proto__ chain and how it works, globals, callback hell etc etc make it a joke of a language for any serious development and god forbig teamwork. You have to use a bunch of libraries just to avoid some of the inefficiencies with the language and from experience people write it however the hell they want to. It's a pile of mess. 

And yes, I know some people use it trying to write big applications.. but in the end it mostly turns out into a disaster, especially when it comes to refactoring. 

It's a bad language that needs to die in fire. We have been forced into it due to web's dependency on it and no real alternatives (even other languages have to compile down into this crap).. and why I am hoping Dart being ECMA certified will be a step towards exterminating this 17-18 year old relic.
Can someone explain what this means ?. What happens next, now that Dart is an approved standard specification ? Why is this good news ? What could now stop other browser vendors to implement it ? It sounds great to my ears but what if no one apart from google cares about this spec ? 
+Boz Bundalo I really really don't understand what you could possibly have against Javascript. It was never intended to be a programming language as you want it to be. So what you need to have multiple plugins or whatever to achieve whatever super-magical-100%-safe-and-clean-app-or-website-or-time-machine that you may want to implement? Don't like it? Use something else. Wait... maybe you want to create something better and in the process change how the whole world operates too? Maybe you should launch a new browser call BozBrowser that runs a 100% perfect programming language called BozScript? Gosh...
ASM.js require no new standard. ECMA standard imply fight for browsers. How ASM.js compare to Dart?
Good to see the open standards process is proceeding smoothly. I don't use or particularly like dart much myself. I'm a .net and Scala fan - dart is too loosely typed for me, and i'm a strong believer that next runtime for the web should be a low level VM that multiple languages can target. But I support any effort to replace JavaScript both as a language and a runtime (because it sucks at both) and wish the dart team luck.
+Boz Bundalo what I had meant earlier was that the language was kind of fun to experiment with as it is so loosely typed. I certainly didn't mean it was a good language, I can't stand it either. For any serious development it's a nightmare, collaboration especially.
Hopefully we'll see something like Node.dart in the future. That would be awesome. I love the whole idea of Node, and use it regularly, but JS is a terrible language no matter how it's implemented.
+Kasper Lund thanks, I hadn't noticed that the DartVM already had such comprehensive asynchronous IO libraries.
+Przemysław Lib asm.js is a different beast: its purpose is not to be handwritten, it is a target for other languages (that's why it is named asm - assembly). Dart on the other end is an interpreted language like JS, Python, Ruby...

As of today asm.js + LLVM are used to "compile" C/C++ apps (games mainly) so that they work inside browsers.

asm.js has the same purpose as NaCl/PNaCl from Google.
I love javascript, because it's everywhere, has a great async mode and if used right you can do wonderful things. To be honest I prefer CoffeeScript but that's just syntactic sugar.
You can do terrible things in all languages, eg Ruby seems to bring out the worst in people.
Dart is also very nice and I hope it will ship with chromium soon. 
Most people who say they dislike JavaScript say so because they have experience with something else that is superior and they resent the fact that they're being forced to use a language and runtime that doesn't really meet their needs, which is pretty much everybody whether they believe it or not.

To us it doesn't matter at all that JavaScript is available everywhere. As both a runtime and a programming language, it is a pile of donkey poo and we (as in the entire industry), need to recognize that and take the hard steps needed to break with the past and move on.

I may not agree with the design decisions that went into the Dart language and runtime (including the fact that it is both), but I cheer for them because at least someone is trying to improve the web platform.
I like Dart, but Google really should have built a lower level VM and then had Dart compile into bytecode that would run on it.
+Seth Ladd Interesting article, they made some really good points. I see why Google decided to stay away from bytecode.
+William Slatton +Seth Ladd Just keep in mind that that article was a little controversial at the time, and there are quite a few counterpoints to be had. 

My view is that the author was looking at the decision (low level IL vs high level IL) from the wrong perspective. From the perspective of just making one programming language, Dart, the fastest it can be on the VM, then of course language level VM wins out (which is where they went with it). On the other hand, from the perspective of creating the best future web "platform" for all stakeholders, which includes multiple languages with varying levels of static/dynamic * strong/weak typing, type systems, and memory management schemes, then a lower level IL is the clear winner.

That being said, the one argument in that article that does hold weight is the difficulty in verifying bytecode for security issues, which really IS a problem and a strong argument for language based VMs in general. But, this is mostly due to existing bytecode formats never being designed to run in a low-trust environment from the beginning. If that were in the design requirements from the start, it would be easier to come up with a lower-level IL format that is more easily verifiable from a security standpoint.

In truth, this is still an area of active research and experimentation so I can forgive the Dart team for making this pragmatic decision. I suspect the real answer is not a bytecode format, but some kind of low-level, machine-readable-only binary AST format. You get the benefits of efficient parsing and download size from bytecode with the benefits of a more easily verifiable abstract syntax tree. Plus an AST-based IL is easier to optimize for different CPU architectures (ARM vs x86) as it makes fewer assumptions in that area, and it's easier for cross-compilers to target (closer to the source language in general).
+Jeremy Bell +William Slatton +Seth Ladd Don't forget that a bytecode VM adds an extra compilation step that we don't have with JS, Python, Ruby and of course Dart. Not having this step, even if very fast (C#), increases a lot your productivity. The best is to have both approaches in order to fill all the needs: interpreted (Dart, JS...) and compiled (Google PNaCl, Mozilla asm.js).

More on this with a 2012 interview of Lars Bak and Kasper Lund that I enjoy a lot:
+Tanguy Krotoff Thanks for the link! I love these kinds of discussions!

I have heard this "you don't have to compile it" argument, 'it' being some interpreted scripting language. I would respectfully counter as follows:

No serious development in any language, dynamic or statically typed, strong or weakly typed, compiled or interpreted, is done without some kind of compilation step, even for 'development'. When I do serious javascript development, I always have a grunt watch task running jshint, jscs, and half a dozen other tasks that run whenever a file is saved (compiling html templates, doing some code-gen task, running unit tests, and so on). That is every bit a "compile" step that a C# compiler would do.

Not only that, but recently I've added a TypeScript compiler task that runs on a grunt watch task. It does an incremental compilation of just the TypeScript files that changed. I am physically incapable of clicking save, switching to the browser, and clicking refresh before that typescript task is done compiling the TypeScript files to JavaScript. The compile task, therefor, adds zero productivity overhead. The browser could have interpreted typescript directly and I would not have felt any difference at all.

Similar tools exist for statically typed languages. For example, there are gradle and sbt watch modes that incrementally compile statically typed java or scala code whenever you click save. I've done some heavy duty scala development before, and despite the scala compiler being one of the slowest on the JVM, the fact that it can incrementally compile code as soon as I click save means I hardly ever notice the time it takes to compile. It's almost always done by the time I'm ready to test the results (or better yet the watch task compiles and immediately runs the tests while I continue working on the next thing).
+Jeremy Bell easy, fast and transparent? that is not my experience: I would be happy to avoid these compilation steps.

Just to clarify you have optional/"nice to have" tasks like JSHint, JSCS, unit tests... and mandatory compilation (TypeScript/CoffeeScript/C/Java/C#, templates concatenation and compilation, LESS/Sass...).
+Tanguy Krotoff my point wasn't that there isn't value in the fast turnaround of interpreted runtimes, just that modern tools significantly close the productivity gap, meaning that particular argument for interpreted runtimes holds less weight than it might have in the past (e.g. as compared to c++ compile times).

It should be noted that compiled vs interpreted is a property of the runtime, not the language. For instance, languages like C# and F# can be "interpreted" in real time (see the ScriptCS and Fakes tools for real work examples of this), and interpreted languages can be precompiled (see jruby, ironpython, and ironruby for examples of this). The only relevant property of the language is how fast it can be compiled relative to other languages. But even that isn't an indication of how advanced the type system is. For instance F# compiles extremely fast but has a more sophisticated type system than c# which compiles more slowly relatively speaking.

And remember in the end that there is always a compiler somewhere in the process. We only call a language interpreted if the compiler is built into the runtime (e.g. the browser).
Add a comment...