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?
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.).
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.
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.
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.
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
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
* 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?
Documentation starts with 'download dart and eclipse' and continues from there. Have you read it?
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.
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?
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 much more of a scripting language than C++. It makes as many code issues static warnings and runtime errors as it can, rather than runtime errors, so you can run a partially incorrect program.
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!)...
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 don't, instead you use your existing connections with corporate management and your massive advertising budget to convince managers to force developers to use it. Even if they are perfectly fine using C++ or Smalltalk.
Well it was clear that since Java was statically typed, it would be possible to write a faster VM for it eventually. And Sun bought up the startup that was implementing Strongtalk, an actual improvement over the bad performance of Smalltalk consumer hardware.
You are missing the point. jQuery fixes the DOM API. Dart's "dart:html" already provides a clean nice-to-use API. All those list-like things are actual Lists. Futures and Streams are also baked into the language. Normalization also isn't needed anymore.
> 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.
> 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.
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.
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.
Dart is faster because it lacks features that JavaScript has, such as dynamic loading or eval or adding fields to objects/classes, and has some special case hacks for SIMD.
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.
Exactly so unless it goes the asm.js route there is probably not much chance it will improve a lot over regular JS. Dart VM is already faster than JS VMs and it will probably get even better and faster in the future.
Imperfections in an art form like Glitch are the substance, not the dirt. Same way, imperfections in JS make it so much fun to work with, for the sufficiently insane. Taking a puritanical approach to programming and weeding out the imperfections leads to a very boring language. I understand the business argument, but creativity requires a certain amount of chaos, no? Or it depends on your theory of creativity I guess. Fair enough.
JS is not an artistic statement, it's a programming language foisted on us by corporate politics and Industry.
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.
>Imperfections in an art form like Glitch are the substance, not the dirt. Same way, imperfections in JS make it so much fun to work with, for the sufficiently insane
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.
Design choices, in terms of the code structure and what is maintainable to you vs another person, are subjective in that they are often driven by personal choice and a sense of what is elegant. Your thinking is too left brained.
Says who? someone who doesn't the discipline to stay polite online? You think all design choices are driven by objective thinking? Funny, but not a valid response IMO.
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 :)
I think that the parent was referring to the fact that it is it's own language with its own VM/runtime. The idea is to create a new language with JavaScript as a compile target. Things like CoffeeScript, TypeScript, etc are much more conservative approaches to dealing with the issues JavaScript has.
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)
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.
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. :)
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...
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.
The original name of the language was LiveScript. ECMAScript is the name of the specification submitted to the ECMA, because Oracle owns the trademark to JavaScript and licenses it to Mozilla for their use; Microsoft decided to call their implementation (created prior to ECMA standardization, I believe) JScript to avoid paying Oracle money.
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.)
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:
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).
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.
This is a personal opinion, but I was honestly surprised how nicely the standardization process is going.
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.
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.
> 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?