

Dart Programming Language Specification [pdf] - tosh
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-408.pdf

======
azakai
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?

~~~
floitsch
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.

~~~
azakai
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".

~~~
floitsch
With the exception of numbers we should be conformant (and if we aren't please
file a bug). A fully compliant dart2js would be theoretically nice, but
practically mostly useless (because of its speed).

The Dart language and its spec are independent of dart2js (which is just an
implementation striving to implement the spec). Clearly there is a huge
connection between both (same team, ...), but in the end we decided to accept
the non-conformance for the benefit of a better language. On the server Dart
developers can already enjoy the more complete number-hierarchy, and, even if
it takes time, I still have the hope that client-side we will eventually be
able to enjoy Dart VMs everywhere. (Call me "optimist" ;)

Wrt debugging: the VM has a mode where it detects incompatibilities. For
example when a number exceeds the 53bits of JS. This should reduce the
difficulties in developing cross-platform tremendously.

~~~
azakai
How much slower would you expect it to be? (You said "mostly useless", but I'm
curious if you have a ballpark estimate.)

I agree the VM debug mode will help a lot.

~~~
floitsch
I prefer not to give any numbers (not even ballpark). It is extremely
dependent on the benchmark, the JS engine, execution order (which function is
optimized first, and/or inlined, ...).

Things get more complex if you want to implement the double/integer
distinction that exists in Dart. That would either require to box integers or
doubles, or to come up with some kind of tagging.

------
mythz
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...](https://groups.google.com/a/dartlang.org/forum/#!msg/misc/xFj2kuiC0fs/qqt_kD2ZSIQJ)

------
d4mi3n
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?

~~~
spankalee
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!

~~~
rdtsc
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/](https://www.dartlang.org/performance/io/)

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

~~~
spankalee
Thanks! Well, thanks to the whole team, it's quite an effort.

Server-side Dart is going to be a really great thing I think. It's by far my
favorite server language already: much less verbose than Java, much more
readable and maintainable than JavaScript, a similar "feel" to Python and Ruby
in some ways, but with more structure and better performance. I'm excited
about the future there.

------
lee
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.

------
idibidiart
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)

~~~
floitsch
[https://api.dartlang.org/apidocs/channels/stable/dartdoc-
vie...](https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart-
js)

~~~
idibidiart
Ha!

------
lars_francke
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
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_francke
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.

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

~~~
Timmmmbob
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.

~~~
pyre
What font does Stroustrup use?

------
skrebbel
I propose a rename to ECMALang to reduce confusion.

~~~
mythz
-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
ECMA languages include:

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

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

~~~
mythz
ECMA is an international standard organization, it's not a language.

ECMAScript is the JavaScript language as standardized by ECMA international:
[http://en.wikipedia.org/wiki/ECMAScript](http://en.wikipedia.org/wiki/ECMAScript)

> Edit: Add edit if you're going to completely rewrite and correct your
> comment

------
supporting
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
That was funny, but the point of this announcement is that the language is
(supposedly) out of Google's hands.

~~~
leorocky
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...](https://en.wikipedia.org/wiki/ECMAScript#ECMAScript.2C_4th_Edition)

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).

~~~
magicalist
You have it backwards with ActionScript. ActionScript 2.0 came out of the
initial years of work of ES4, and ActionScript 3.0 came out after yet more
work from TC39. Both were designed to directly take what came out of the ES4
process and fold it into ActionScript (so much so that you'll recall that
originally Mozilla was going to use Adobe's Tamarin ActionScript JIT compiler
as a starting point for their Firefox ES4 engine[1]).

Adobe was a big proponent of many of the big features in ES4, but so were
Mozilla and others on the committee. Adobe was hoping that the work in AS2
(and eventually AS3) would anticipate what was coming and that JavaScript
developers would be able to easily move back and forth between the web and
Flash/Flex/whatever else they had planned at the time.

Of course influence went the other way as well: Adobe's experience with the
needs of ActionScript 1.0 developers were informing what was focused on in
designing ES4...but that's exactly why you bring people into committees, to
help guide what comes out of them.

[1] [http://www-archive.mozilla.org/projects/tamarin/](http://www-
archive.mozilla.org/projects/tamarin/)

