Dart Programming Language Specification [pdf]
ecma-international.org
ecma-international.org
> 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?
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.
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".
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.
I agree the VM debug mode will help a lot.
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.
foo async => 42;
Specifically, why would one consider moving to Dart from any of the above languages?
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!
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)
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.
The drop in max latency is really notable. I assume that was caused by garbage collection improvements, but I can't find any details about what GC techniques the Dart VM currently implements.
* 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.
Eclipse users? How could you tell that the documentation is aimed at Eclipse users? What is it about documentation that could make it Eclipse user biased?
* No npm, and little documentation emphasis on running on servers
Dart is a different language to javascript so its got it's own package manager called pub. If you google "dart package manager" you will find it straight away. If you look at any dart documentation or examples you will see references to it. Did you expect that if you change your programming language you would have the same package manager? No other programming language has npm either.
* Poor integration with massive amount of existing JS technologies
I think it's pretty good but they are working to improve it. See https://news.ycombinator.com/item?id=7972907
* Surprising amount of redundant tokens for a language released in 2011. Semicolons, really?
A surprising amount sounds like there are very many indeed. Apart from delimiters like semicolons and braces (which have advantages in a modern language and are used by many) can you list some of the other redundant tokens? Dart seems very terse to me.
* Most importantly: it's been 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.
Remember that Dart was opened up long before it was recommended as being stable. Even at that, can you name one other language where the user had some choice (unlike, say, js) that had widespread adoption in a 3 year timeframe?
npm is an ecosystem as well as a software tool, and pub is too. pub is tiny compared to npm.
Yes, braces are redundant in most cases too and can lead to errors where code looks different from how it executes. Main is also unnecessary, but I've been told the dart docs include it without needing to. Not having a default return type is a waste of programmers time, to return void, don't return anything. All these things reduce signal/noise when reading dart.
If you don't think extra tokens mean extra work I welcome you to do some testing and get numbers to prove it.
Python 1 got pretty popular in Unix circles immediately: everyone could see it was better than Perl for most purposes. The cleanliness of the language made people overlook PyPI being, at the time, so poor compared to CPAN.
- 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?
[1] http://en.wikipedia.org/wiki/Dart_(programming_language)#Bro...
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?
Dart is also strongly typed, doesn't have pointers, has GC, has no shared-memory concurrency, uses dynamic dispatch, don't require a compiler (for development), has full access the the DOM (with a much nicer API than in JavaScript!)...
Like, when I use DOM in any language, it will be conform the the DOM spec, like having the same classes, methods, etc.?
This article has a nice summary of the improvements https://www.dartlang.org/articles/improving-the-dom/
For instance, rather than use callbacks everywhere, most of our async APIs return Futures and Streams. All the "Array like objects", like NodeList, are actually lists in Dart. You can iterate over them and modify them list any other list. element.classses.add('foo') works, as well as some jQuery-isms like element.classes.toggle('foo', show). setInterval is replaced with the standard dart:async Timer class.
There is a ton of cleanup in the dart:html library that makes programming the DOM nice. I'd say there will never need to be a jQuery equivalent in Dart.
You should read the "Criticism" part of this page.
http://en.wikipedia.org/wiki/Dart_%28programming_language%29
Apple, FF, MS are all against Dart.
Google "percentage of website power by Jquery" and tell us how are you going to convince 50% of websites to abandon JQuery and use dart.
Dart today = GWT of yesterday!!!
> Apple, FF, MS are all against Dart.
Oliver Hunt isn't Apple. Brendan Eich isn't Mozilla. He doesn't even work for Mozilla anymore.
Mircosoft's JavaScript team also isn't equivalent with Microsoft itself. It also would be pretty weird for them to endorse Dart.
They have TypeScript, which sells Visual Studio, which sells Windows licenses, which sells the Microsoft ecosystem, which sells Windows Server licenses.
That's how they operate and there is nothing wrong with that, really. If you have a large existing JavaScript codebase which you want to keep, TypeScript is a pretty good choice.
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.
I'm assuming that you mean on the browser, or are you targeting dart => dart2js => nodejs as the primary means of server-side deployment?
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.
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.
It makes a lot of sense if performance of Dart VM is about 1.5x or so faster. It is especially good for some of the math (or SIMD related things).
> You could remove all types from a TypeScript file and it'll probably run fine on any existing JS VM that supports ES6.
Right, so does Dart. So they are the same there.
One could easily tweak JavaScript to have the same lack of features and same performance gains (many could be done in asm.js style) so I do not see how Dart is relevant except as a way to not participate in the evolution of JavaScript.
Personally I feel that getting even a 50% boost on a scripting language that's never going to be as fast as C# or Java anyway, by making an additional incompatible VM, is totally foolish. Both VMs will be needed for many years, and this collateral bloat is just not worth the benefit. When you look at performance over JavaScript + asm.js the gains are seen largely where performance does not matter much anyway.
Also, mental chaos begets creativity. Chaos emerging from tools only serves to impede the expression of those using the tool. I'm not sure how you can argue how a tool that works against the user in a non-performance art is a good thing.
Programming is not like "art" in that anything goes as long as it's an artistic statement. Programming is pragmatic and goal oriented, and the goals are not the expression of the inner self.
Sure, you can do some programming with an artistic intent (e.g code obfuscation stuff), but that's the exception rather than the rule. "Code as poetry" and "Hackers and Painters" are tired metaphors.
As for "glitch", those imperfections are not actual imperfections, but desirable and genre-defining elements. Glitchs exists because it HAS those. Programming doesn't exist to have imperfactions -- it exists to execute some kind of task.
That's about as valid as "Street cleaning is an art form, if for you street cleaning is art".
To quote an old essay:
= = =
"Let me say it simply - hackers are nothing like painters.
It's surprisingly hard to pin Paul Graham down on the nature of the special bond he thinks hobbyist programmers and painters share. (...) The closest he comes to a clear thesis statement is at the beginning "Hackers and Painters":
"Of all the different types of people I've known, hackers and painters are among the most alike. What hackers and painters have in common is that they're both makers."
To which I'd add, what hackers and painters don't have in common is everything else. The fatuousness of the parallel becomes obvious if you think for five seconds about what computer programmers and painters actually do:
Computer programmers cause a machine to perform a sequence of transformations on electronically stored data.
Painters apply colored goo to cloth using animal hairs tied to a stick.
It is true that both painters and programmers make things, just like a pastry chef makes a wedding cake, or a chicken makes an egg. But nothing about what they make, the purposes it serves, or how they go about doing it is in any way similar.
Start with purpose. With the exception of art software projects (which I don't believe Graham has in mind here) all computer programs are designed to accomplish some kind of task. Even the most elegant of computer programs, in order to be considered a program, has to compile and run [1]. So just like mechanical engineers and architects, computer programmers create artifacts that have to stand up to an objective reality. No one cares how pretty the code is if the program won't work.
The only objective constraint a painter has is making sure the paint physically stays on the canvas (something that has proven surprisingly challenging). Everything beyond that is aesthetics - arranging colored blobs in a way that best tickles the mind of the viewer.
This difference is what makes programming so similar to engineering, which also tries to create beautiful things in the face of objective constraints, but it's a parallel that really rankles Graham.
http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm
= = =
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.
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.
Related write-up: http://news.dartlang.org/2013/04/why-blossom-is-switching-to...
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.
That IS key to the slippery slope of adoption.
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.
You're just much more used to monospace.
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.
Dart, Javascript, Actionscript, Jscript, QML, QtScript, InScript
Which are compiled/executed according to EMCA-262 OR ISO/EIC-16262
ECMAScript is the JavaScript language as standardized by ECMA international: http://en.wikipedia.org/wiki/ECMAScript
> Edit: Add edit if you're going to completely rewrite and correct your comment
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.)
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.
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).
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.
I was part of the team that started Dart (right place at the right time :), and helped design the language. Obviously we have some emotional binding to the language and would like to drive it into the right direction, but most of us are perfectly happy with others taking the relay.
We still have some ideas and proposals that we have worked on and that we want to champion, but all in all I just hope that the TC52 members will do a good job.