Dart Programming Language Specification [pdf]

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-408.pdf

by tosh • 12 years ago

134 86 12 years ago

ecma-international.org

skrebbel3• 12 years ago

I propose a rename to ECMALang to reduce confusion.

mythz3• 12 years ago

-1 Never heard of ECMALang.

Edit clarification:

ECMA International is a well-known international standard organization. The existing title of:

The Dart Language is now an ECMA standard

Makes a lot more sense than

The Dart Language is now an ECMALang standard

Which is an unknown term, to hypothetically mean it's a Standard for a language published by ECMA, which is exactly what the existing (more familiar) title suggested.

valarauca1• 12 years ago

ECMA languages include:

Dart, Javascript, Actionscript, Jscript, QML, QtScript, InScript

Which are compiled/executed according to EMCA-262 OR ISO/EIC-16262

skrebbel3• 12 years ago

I did not propose we rename the submission title, but the language. Also, it was a joke, in reference to that other language that starts with the characters "ECMA" and whose many other confusing multi-meaning names have become notorious.

d4mi3n• 12 years ago

I've read about Dart, but I haven't used it much in practice. What does it do better than similar languages that compile to JS (CoffeeScript, Typescript, etc)?

Specifically, why would one consider moving to Dart from any of the above languages?

chrischen• 12 years ago

Dart compiles to javascript, but it's just a feature to ease migration. It also has its own VM.

spankalee9• 12 years ago

dart2js is not just a feature to ease migration. It's the primary means of deploying Dart code, and will be so for a long time, even if/when the Dart VM gets into Chrome.

rdtsc5• 12 years ago

Few reasons:

There is a native VM for it that is fast and it has the highest chance of getting implemented in a browser (let's say higher than Typescript).

There is good tooling behind it (IDE, package system).

Google supports it. Whether we like it or not that makes a huge difference.

Native VM has good IO characteristics and can be used on the server side as well. (So can start using that on the server side without having to wait for browsers to embed it).

Does away with Javascript warts better than CoffeeScript.

idibidiart9• 12 years ago

The imperfections in Javascript is what makes it beautiful.

http://www.utne.com/mind-and-body/wabi-sabi.aspx

lukasm3• 12 years ago

Typescript does not have VM

skrebbel3• 12 years ago

(let's say higher than Typescript)

That little side note there makes no sense at all. The runtime semantics of TypeScript are exactly the same as JavaScript. TypeScript is little more than some ES6 notation (class, =>, etc) plus compile-time type checking.

You could remove all types from a TypeScript file and it'll probably run fine on any existing JS VM that supports ES6.

lukasm3• 12 years ago

The great thing about Dart is that it breaks backward compatibility with js. The bad thing about Dart is that it breaks backward compatibility with js :)

discreteevent2• 12 years ago

Not sure what you mean by breaking backward compatibility. It generates js. Does e.g. Clojurescript break backward compatibility with js?

spankalee9• 12 years ago

Hi, I'm on the Dart team, I'll try to answer the best I can.

CoffeeScript doesn't really change the semantics of JavaScript at all, it mostly is just a new syntax. I don't fine the syntax to be the worst thing about JavaScript, so CoffeeScript has never seems that compelling to me.

TypeScript does a little more by offering types and classes, but it's still a superset of JavaScript and can't fix major issues because of backwards compatibility. I like TypeScript, but I prefer to go a lot farther.

Dart fixes a lot of fundamental issues with JavaScript, largely related to having a well-defined structure that humans and tools can reason about. This makes it easier for the VM to optimize too.

Here's a grab bag of things that Dart has over JavaScript:

* Dart has libraries, and library scope, no global scope. All code must be imported to be used. * It has true classes with inheritance, interfaces and mixins. Objects are closed, so you can't accidentally add a new property because of a typo, and you get static warnings about undefined property names. * Dart has optional type annotations and a static type checker. We catch a lot of bugs when porting JavaScript code to Dart and adding types. * There are no top-level statements, only variable, function and class declarations. A program always starts at main(). * True lexical block scoping. No function scoping. * Final variables and library private names. * There are generics and they are reified. * 'this' is lexically bound, removing a whole swath of confusing patterns and bugs. * There is no implicit type coercion or boolean conversion. Being more explicit in boolean contexts reduces bugs. * There are real collections like Maps, Lists, and Sets. They are interfaces and can be implemented by users. * Dart has operator overloading * There is an actor-like unit of concurrency call Isolates * Metadata annotations (@something) can be processed by build-time and runtime tools. * noSuchMethod() let's you catch undefined method calls.

All combined, I find Dart to be much easier to code in and much, much easier to read and navigate. Jump into a new Dart codebase and the types give you a lot of information. Even in code that's not typed, because it's statically analyzable you can jump to definitions and get documentation for fields and functions. At Google we see productivity is _much_ higher on Dart projects.

Hope that helps a little!

rdtsc5• 12 years ago

Hey great work, congratulations!

I like the performance of Dart VM for server side. I remember it was so-so initially and then it got a huge performance boost. You could see a sharp jump on

https://www.dartlang.org/performance/io/

(now it almost disappeared to the left side due to the timeline moving)

phloxicon• 12 years ago

That's really helpful. Thanks.

I have another question. C++ already has types, a main function, collections etc. and is really fast. What are the advantages of Dart over C++ with emscripten?

skybrian• 12 years ago

I don't disagree but I'm wondering if a couple of these are ready to use yet:

- Are metadata annotations really usable (at runtime)? If they're based on mirrors then it's my understanding they're to be avoided when using dart2js.

- I haven't seen isolates used much. What's the status for them?

nailer2• 12 years ago

Here's a list of Dart drawbacks. I like Dart's clean DOM API for the record, but here's what stops me using it:

* Documentation aimed at Eclipse users who are familiar with Java and .net that like cutting edge web technologies, rather than existing web developers.

* No npm, and little documentation emphasis on running on servers

* Poor integration with massive amount of existing JS technologies

* Surprising amount of redundant tokens for a language released in 2011. Semicolons, really?

* Most importantly: it's been nearly three years and Dart has made little to no impact on the world of frontend development. Even non-production Dart use is unheard of on frontend circles, and has less users than coffeescript or Typescript.

optymizer• 12 years ago

Hi! What is the current state of browser adoption for Dart? Wikipedia seems very pessimistic about it [1].

[1] http://en.wikipedia.org/wiki/Dart_(programming_language)#Bro...

ahoge2• 12 years ago

What does [Dart] do better than similar languages that compile to JS (CoffeeScript, Typescript, etc)?

CoffeeScript doesn't really help with scaling. It's basically just a slightly more compact JavaScript dialect. Personally, I don't see the point.

TypeScript is closer. It offers type annotations and more structure. Being a strict superset of JavaScript also means that it can't fix any of JavaScript's issues. However, it also means that it can seamlessly interact with JavaScript.

Dart is a clean break. Straightforward, nice semantics, and none of the weird stuff. There are official code conventions, a package manager, a doc generator, and a built-in way to do inheritance. Compared to JS, this skips a lot of research and pointless discussions. Naturally, it also avoids the associated compatibility issues and annoyances.

The VM is also a big advantage, because you don't have to compile your code hundreds of times a day during development.

As a result, the compiler can perform rather heavy optimizations, because compile speed isn't the top priority anymore.

Having that VM also allows you to write command line tools and web servers. It can be also embedded in other applications.

Anyhow, if you know something like C#, you already know most of Dart's syntax. Just give it a try. You can be productive on your very first day. It's really that straightforward.

insaneirish• 12 years ago

My goodness. In what world does it make sense that a programming language standards document uses a variable width font for code samples?

qubyte• 12 years ago

The bulk of the document is written in LaTeX, and it is possible that they used the listings package to write the code samples. See section 2.10 of The Listings Package document for variable column code samples. In more regular code snippets, the results can be very nice. http://mirror.ox.ac.uk/sites/ctan.org/macros/latex/contrib/l...

Timmmmbob• 12 years ago

It actually works quite well if you pick the right font. Stroustrup uses it in The C++ Programming Language and it is easier to read.

You're just much more used to monospace.

pyre3• 12 years ago

What font does Stroustrup use?

supporting• 12 years ago

In Memoriam, Google Dart, 201X:

A few years ago, Dart was Google’s first foray into web programming languages. Built as a “20 percent” project, Dart developers started conversations, and built web applications that had never existed before. Dart helped shape the future of the browser before people really knew what “Beyond JavaScript” was.

Over the past decade, TypeScript, CoffeeScript, ClojureScript and ES7 have taken off, with communities springing up in every corner of the world. Because the growth of these communities has outpaced Dart's growth, we've decided to bid Dart farewell (or, "adiós"). We'll be focusing our energy and resources on making these other development platforms as amazing as possible for everyone who uses them.

We will shut down Dart within the next 3 months. Until then, there will be no impact on current Dart users, to give the programming community time to manage the transition. People can transpile their applications into JavaScript using Google Takeout (available until next year). Starting today, it will not be possible download or patch updates to existing copies of the Dart compiler.

Dart, the language, may be going away, but all of those incredible web apps that Dart users have created will live on. We are preserving an archive of the best of the bunch, which will be available online during this transitional period. If you don't want your app or name to be included in the community archive, you can remove Dart permanently from your Google account by visiting your YouTube preferences page, and clicking on "Advanced Settings". Please visit our Help Center for further details.

It's been a great few years, and we apologize to those still actively using the language. We hope people will find other programming communities to spark more projections and build even more amazing applications for the next decade and beyond.

---

(This is just in good fun ;) Likely? No. Possible? Sure seems to be.)

guelo• 12 years ago

That was funny, but the point of this announcement is that the language is (supposedly) out of Google's hands.

leorocky• 12 years ago

Nay, the big companies that care a lot about these languages own them through and through. Look at Adobe's attempt at converging ActionScript and JavaScript in the abandoned ECMAScript 4th edition:

https://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_4th_E...

I think Microsoft was key in killing this. With respect to Dart, Google will have the ability to control Dart's future as long as it wants to and if it somehow lost control of the ability to shape the spec it will just do its own thing anyway, just like they have with Blink and standards (directoryReader comes to mind).

ternaryoperator• 12 years ago

Yeah, but I think the point is that ECMA standardization does not confer longevity. If Google abandons Dart, the language is no more alive or dead because it's been standardized by ECMA. The risk to Dart developers is effectively the same.

rdtsc5• 12 years ago

TypeScript, CoffeeScript, ClojureScript and ES7 have taken off, with communities springing up in every corner of the world.

I guess if this user claims to represent those communities, I wouldn't want to be a part of them. In any corner of the world.

idibidiart9• 12 years ago

The ability to mix JS and Dart in the same web app (and maybe do something crazy like a an inter-VM messaging channel) would be vital to the adoption of Dart, IMO. That way, an organization (hypothetically speaking) can introduce Dart into their 20K+ lines of Javascript one feature at a time, without the burden of refactoring (feature isolation)

floitsch5• 12 years ago

https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie...

idibidiart9• 12 years ago

Ha!

spankalee9• 12 years ago

Florian pointed out dart:js, but we know we need to continue to make this even better and easier.

Ultimately we want you to be able to seamlessly use Dart code from JavaScript, and get some of Dart's benefits when using JavaScript from Dart. Stay tuned.

idibidiart9• 12 years ago

<<Ultimately we want you to be able to seamlessly use Dart code from JavaScript>>

That IS key to the slippery slope of adoption.

tosh2• 12 years ago

We (https://www.blossom.io) are using Dart alongside JavaScript (CoffeeScript) right now.

You can call JavaScript code from Dart and vice versa. https://www.dartlang.org/articles/js-dart-interop/

This was a great pragmatic stepping stone for us as we moved from a JavaScript only code base to a much saner development experience thanks to Dart.

azakai3• 12 years ago

Here's the part about numerics differing between the VM and dart2js:

A numeric literal is either a decimal or hexadecimal integer of arbitrary size, or a decimal double [..] In principle, the range of integers supported by a Dart implementations is unlimited. In practice, it is limited by available memory. Implementations may also be limited by other considerations. For example, implementations may choose to limit the range to facilitate efficient compilation to Javascript. These limitations should be relaxed as soon as technologically feasible.

So in principle Dart has bignums and doubles, but does not specify anything about how "big" the bignums are supposed to be, so a conformant implementation can simply not implement bignums (i.e. they are the size of the integers that fit in doubles).

This technically makes dart2js conformant, even though it in practice has different numeric types than the VM. That's fairly clever from a spec perspective, but worrying from a practical point of view.

Anyone know what the status of bignums in JS is? The spec says this will be fixed when "technologically feasible", but I can't find information about (1) what overhead dart2js currently suffers when it does implement bignums, and (2) when this is expected to become feasible, and how. I know some dart VM people are active in the comments here - is there any public info on those two issues?

floitsch5• 12 years ago

Disclaimer: I work on dart2js.

Dart2js is not conformant. You could, maybe, twist the meaning of the spec this way, but it goes against the spirit of the sentence and the spec.

Tbh we never implemented a fully compliant dart2js backend. We have seen how slow the output is when some of our optimizations don't trigger (i.e. when we have bugs) and numbers are not correctly inferred.

Eventually we would like to give it a try, but there are much more important and useful issues we want to fix first.

In practice, numbers are a surprisingly small problem. Programmers have learned to look out for big numbers, and, while a nuisance, they are rarely the source for bugs.

azakai3• 12 years ago

Thanks for the info!

So there's not an urgency to make dart2js conformant, it sounds? I can understand if there's lots of other stuff to do, yeah - I suppose I am only surprised because the language is at version 1.5 and has a full spec, which could be my fault for assuming that meant it was more "finished" (by some vague meaning of the term).

I am still worried about numbers, though. Yes, programmers mostly know about this stuff, but rare and hard to debug issues are the concern when you have different numeric types than expected, in my experience (for example, in pyjamas, emscripten, etc.).

edit: clarified what I meant by "finished".

mythz3• 12 years ago

Also announced today: Dart to get async/await syntax sugar to simplify async programming:

    foo async => 42;

https://groups.google.com/a/dartlang.org/forum/#!msg/misc/xF...

lars_francke2• 12 years ago

Any idea if anyone's working on an sbt-web based plugin for Dart support? I'd love to use it in Play as I'd rather like to learn Dart than JavaScript.

photex• 12 years ago

I started hacking together a plugin based on sbt-purescript. I could make a repo on github if you're interested in working together. My biggest stumbling blocks are that I don't know much about working with Dart and I've never made an sbt plugin before. :)

lars_francke2• 12 years ago

That's great! I'm in the same boat as you are, never made a sbt plugin before and especially not one of those sbt-web ones.

I'm afraid though I don't have much time to spend on this at the moment so I'll have to defer learning this until later.

lee• 12 years ago

I tried to give Dart a go at work. We invested about a month's worth of work for a 4-person team into it, kicking the tires, and giving it a go before we gave up and went back to Javascript.

I hope Dart succeeds, as it's a really nice language. And it's great to see the spec published as an ECMA standard. It was a dream to work in compared to Javascript, and I was overly hopeful that it could be used in production. But we found out within a month that it is not.

What killed it for us was browser support. The supported browsers for dart2js is the "latest chrome and firefox" and in the forums they planned to support the last two internet explorer versions. At the time of our experiment, IE 9 and 10 were supported but not 11, even though 11 was out for a few months already. At the time, our app would randomly crash in IE11.

So this forced us to ask two questions: 1) will this happen in future IE releases where we leave a portion of our early-browser-adopting users SOL, and 2) a very large portion of the population is still stuck on older versions of IE and FireFox.

So Dart wasn't a good fit for us not because of the language, but because we simply couldn't use it in our business environment where we had to support actual users who use the latest versions of IE as well as older ones. We were already dropping all IE8 users to support Dart, but looking today they plan on dropping IE9 support soon too which makes up a large portion of our users.

Anyhow, I hope Dart succeeds, I really do, because it's a great language and I'd much prefer to use it over javascript. But unless its current implementation is more business friendly and realistic we can't use it.

Dart Programming Language Specification [pdf]

Related Stories