▲ 134 points
back
86 comments
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?
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.
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".
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.
Also announced today: Dart to get async/await syntax sugar to simplify async programming:
foo async => 42;
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?
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!
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)
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.
It's not obvious, but you can click and drag the chart to see older results.
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.
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.
* Documentation aimed at Eclipse users who are familiar with Java and .net that like cutting edge web technologies, rather than existing web developers.
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?
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?
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...
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?
> 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.
Dart compiles to javascript, but it's just a feature to ease migration. It also has its own VM.
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.
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.
> (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.
Typescript does not have VM
The imperfections in Javascript is what makes it beautiful.
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 :)
Not sure what you mean by breaking backward compatibility. It generates js. Does e.g. Clojurescript break backward compatibility with js?
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.
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)
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.
Related write-up: http://news.dartlang.org/2013/04/why-blossom-is-switching-to...
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.
<<Ultimately we want you to be able to seamlessly use Dart code from JavaScript>>
That IS key to the slippery slope of adoption.
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.
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. :)
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.
My goodness. In what world does it make sense that a programming language standards document uses a variable width font for code samples?
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...
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.
What font does Stroustrup use?
I propose a rename to ECMALang to reduce confusion.
-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.
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.
ECMA languages include:
Dart, Javascript, Actionscript, Jscript, QML, QtScript, InScript
Which are compiled/executed according to EMCA-262 OR ISO/EIC-16262
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.)
> 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.
That was funny, but the point of this announcement is that the language is (supposedly) out of Google's hands.
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).
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.