The influence of Dart on ES6 and 7 apart from SIMD (John McCutchan shout-out, John did the Dart work and then worked on https://github.com/johnmccutchan/ecmascript_simd; I had some small helpful role to do with the project involving Mozilla and Intel, too) and the courage and validation -- not the idea, which pre-dates Dart -- of giving the for (let...) loop a binding per iteration in ES6 as in Dart, there has been no influence or help from Dart.
Modules in ES6 have nothing to do with Dart, and the work started in 2010, well before Dart ("Dash") leaked. Classes too pre-date Dart, in some ways they go back to JS2/ES4 of the 1999-2003 era, and ES4 of the 2006-8 era.
CoffeeScript owes a lot to Ruby and Python, of course, and I did design-champion fat arrow functions into ES6, inspired in part by CoffeeScript. ES6's for-of loop is responding to the same gravity-well as CoffeeScript's for-of, but it differs in substantial aspects. And so on.
Languages influence one another -- news at 11 -- but Dart did very little intentional uplift work for JS. SIMD is the big and very good exception to this norm. Better late than never, I say. Now is a good time to help get value objects including bignums into ES7.
To be clear, I didn't say that Dart or CoffeeScript associated people actively meant to be a guide for JavaScript (I'm pretty sure that having CoffeeScript and Dart effectively subsumed into JavaScript wasn't the goal), but the fact that these languages existed and has neat features did served as a guide for evolution of JavaScript.
Thus I am making the case of much weaker case of languages influencing each other, rather than a stronger case. And there is massive influence going on here, whether intentional or not -- the speed at which features of Dart and CoffeeScript being pulled into JS is very rapid.
I think your comments actually bare this out -- Dart people helping with SIMD, and you being inspired by CoffeeScript.
You wrote "The same is actually happening to the unique features of Dart such as typing and SIMD and better modules." My reply: no, yes (thanks to bottom-up work by John McCutchan, not "Dart people" plural -- there you go again), and nope. Any types for ES7/2016 or beyond are likely to be based on TypeScript, Flow, and V8's SoundScript experiment, not on Dart. Modules in ES6 have no relation to Dart modules/packages.
Really, "exaggeration" doesn't being to capture the false overreach of your first comment, and walking back from it to vague "everything's influencing JS" isn't helping.
Apart from SIMD, Google by investing in Dart at cost to JS (recreated V8 team; replace-not-embrace strategy for ~5 years) missed out on uplifting ES6 to have bignums and other things that would materially aid correctness and performance of dart2js, which is now the only way forward for Dart in browsers.
I hate playing Cassandra, but the good news is that Troy didn't fall: JS prevailed, at some unnecessary cost, and as predicted. See https://news.ycombinator.com/item?id=2982949 et seq.
(1) I am referring to the high level features of Dart and CoffeeScript, not the specific implementation of features. Specifically I am referring to the clear reduction in CoffeeScript/Dart positive differentiators over the past few years, mostly because future JavaScript (es6/es7) is moving aggressively to close the gap and then go beyond Dart/CoffeeScript. This is a great thing.
(2) I am a complete outsider to the standardization process - I actually know no one involved in the process. So why did I make the inference then so confidently? I've been doing software product development in competitive industries for a couple decades now. I know how it works. People are always influenced by competitors to push ahead faster and smarter, especially competitors that try to jump ahead.
This comment of mine from two years ago sums up my feelings of Dart and its influence on JavaScript: https://news.ycombinator.com/item?id=5728786
Any resemblance you might find between Dart and ES6/ES7 would be because of Darts resemblance to either CoffeeScript or TypeScript, languages that did in fact influence ES6 and ES7.
My personal view: I don't think Dart is the sort of language Javascript wants to be like at all. Also, totally off topic regarding your comment of 2 years ago: Java has never kept up with C# has always been years behind and still lacks many features that C# has had for ages. The only reason people still use Java is that C# had no enterprise backing on non-Microsoft platforms and its main implementation was proprietary. These things are changing, and I think that will be the end (finally) of Java.
There is still no end to end story for dev on Linux/Mac with MS backed tools (Mono is not .NET).
"and I think that will be the end (finally) of Java."
just day after Google will take C# as main dev lang for Android...
IMHO It's more likely that Dart will become new Android's main lang.
...seriously. April the first is still 5 days away.
I know that. My point is you go to dartlang.org and get the IDE with SDK with single download for Mac, Linux or Windows and use it now.
With .NET you can't do the same now on non-Windows (you can use Mono but it's not MS project) Dart is designed to do webdev and .NET isn't
I apologize for it being open to that interpretation. I do view most of your criticisms to be based on this unintentional straw man interpretation of my points: http://en.wikipedia.org/wiki/Straw_man
You admitted both the influence on you of CoffeeScript (e.g. fat arrow) and also that the Dart SIMD standard guy did the ES7 SIMD standard. Thus at minimum both CoffeeScript and Dart have influenced directly what has ended up in future versions of JavaScript via the JavaScript standards people. So that original claim of mine is true at minimum, only the qualification of the influence being significant/large is at question.
Near equivalent features to those of Dart and CoffeeScript are rapidly being added to future JavaScript, including fat arrow, typing, classes, SIMD, Futures, async/await, etc. Whether or not these features are directly based on Dart or not doesn't change the fact that it is happening. So that original claim of mine is also true.
E.g.: https://robots.thoughtbot.com/replace-coffeescript-with-es6
The intensity of this argument about an admittedly overly vague hacker news comment is surreal.
While I respect your work highly, benefit from it significantly, and it wasn't my intention to diminish your contributions or effort or anything else, I can not continue this.
Again, modules in ES6 started before Dart ("Dash") leaked.
Your original comment said "Thank you Dart for showing us the way." Happy-clappy nonsense!
Why am I on the warpath?
First, sloppy history retelling -- even if just fannish exaggeration -- is bad in itself.
Second, and I've gone on the record about this since 2011, Google chose the wrong "REPLACE JS BECAUSE IT CANNOT BE FIXED" strategy, and wasted years and megabucks. Their choice, but not something to congratulate them over. We could have had even more in ES6 if the V8 team had not been reset and JS back-benched as it was. That cost years.
Third, the meme you're spreading is that JS is incompetent or severely hobbled without being shown the way by enlightened others. This does a disservice to many people including the V8 team (the new team) members working in earnest on JS via implementations and TC39. It's a particular falsehood to which I object as a peer of those people on TC39.
Dart as an intentionally designed, full-time-job-for-60+-people, good and well-done project at Google, creating useful and coherent tools as well as the language itself? A fine thing in isolation, ignoring the actual history, global strategy, and consequent trade-offs.
Dart as the thing that showed JS the way (same for CoffeeScript, but let's defer that and focus on Dart)? A fraudulent claim that covers up real mistakes in strategy made by Google, which cost big time and money, not just for JS and the Web, but bad also (in light of this week's news) for Dart.
Why was the strategy bad for Dart? One example: only now, finally, might bignums get into ES7/2016. They could have been in ES6 and in V8 and other engines by now, since we were working on them since 2010, but without a champion who saw the priority and paid someone to spec and implement them in V8.
Do you see my point? Please do not play games about me "admitting" SIMD and maybe one other something else came from Dart. I've written that many times in multiple threads without prodding, on HN and on twitter. This is not an ego match. It's about accurate attribution of history, work, influence, and causality.
Also, you do realize that I wrote this to a Dart audience to encourage them to return to JavaScript -- and you do not convince anyone to change their minds by being an asshole towards their work.
So, really sloppy original comment with multiple false claims. Should I just put up with that as part of HN's descent to /. quality? :-(
/be
That's exactly right. We have a bunch of people working feverishly on more human-friendly JS output:
Bignums are good, in Dart as in other languages. On the agenda for "Harmony-era" ECMAScript, going back to 2009:
http://wiki.ecmascript.org/doku.php?id=strawman:bignums
More recent work generalizes value types into an extension mechanism for JS, so you can have built-in and user-defined numeric types with operators and literals.
Or are bignums and decimals the same thing? (not sure).
Most financial applications deal with currencies each of which had a smallest indivisible unit in the application, which makes bignums most appropriate. But bigdecimals (or even arbitrary precision rationals) may be preferred in certain financial applications.
[disclaimer: I'm on the Dart team]
Whether you like JS or don't, I think we can all agree that it stinks to have only one choice for client-side scripting.
Sorry, using the present tense for things that will be in browsers years later (hopefully) is a common practice that's an issue with me. Let's stick with what people can actually use today.
Also, pointing to features people can use in different dialects of JavaScript is not really fair. Just about everything you can think of has been experimented with and probably deployed somewhere. It doesn't count unless it's all available in the same toolchain and can be used in a unified way while writing a single app.
ES7 async/wait is available now via the ES7 polyfill Babel.js: http://babeljs.io/
There are a ton of polyfills available right now for ES6/ES7 features: http://kangax.github.io/compat-table/es7/
BTW I also think that the current state of aggressive polyfills is also influenced by Dart's compile to JS functionality. :)
If that's the metric we're applying, Dart fares no better...
All via dart2js
OTOH: JS has the largest module system of any programming language ever, which also tends to make it pretty productive.
What are optical types? I've never heard of this term and Google turned up nothing on it.
That said, there is a glass ceiling of how far you can go with iteratively improving JavaScript.
I'm glad that there are more ambitious languages like Dart that are designed from scratch by people with amazing background in language design & runtimes.
Having worked with Dart now over many months at Blossom (https://www.blossom.co) I can't imagine going back to writing JavaScript (not even ES.next++). Dart is conceptually much simpler. I really encourage you to give it a try.
Dart gives you a consistent and simple platform (stdlib, packages, tooling, …) to build upon that works well 'today'. It is easy to pick up and be productive in (compared to JS and all the things you have to train people on about its ecosystem).
With this new direction I expect the interop story with JavaScript to improve further as well.
When a new language is created, its feature set is a product of the times it is created in. i.e. what features are considered useful, popular, best practice etc. Of course times change and with it what this set of desirable features is. Languages evolve by adding support for some of these new features. But adding these new features whilst preserving the old becomes increasingly difficult and the new features tend to be somewhat hobbled and don't fit that well with the older features. For the first 10 years or so this tends to be ok but when languages get to the 10 - 20 year mark they start looking increasingly like frankensteins monster - a mixture of parts from different places / eras, none of which work terribly well and which don't fit that well with others. At some point IMO it's worth jumping to a new language despite the smaller community and package availability. But it's often only when you do try it for a while when you realise how much better the dev experience is compared to the frankenstein languages which have on paper adopted similar features. To me this is where Java, JavaScript, Python etc are now. On paper they can claim many of the features now that Dart has but the experience using them is not that of using those features in Dart.
I can't imagine there are many decent developers who if they really give dart a proper go, wouldn't much prefer to work with it than JavaScript.
Just because JavaScript is the de facto runtime of the web doesn’t mean we all have to develop in it. I’d much rather write in Dart (or CoffeeScript, TypeScript or whatever) than JavaScript—and then only I have to.
The writing is on the wall already. If Dart hasn't the chance to become a natively supported language, why would anyone pick it as a compile-to-JavaScript language, given there are so many superior options?
I don't think that the premise ("given there are so many superior options") is a non-controversial assertion. Which is probably why people who reject it would (and have been) picking it as a compile-to-JS language for web-facing projects.
The focus on compile-to-JS and JS interop for the web announced in the blog post makes Dart a more, rather than less, attractive language for web development, because it eases fears that taking full advantage of Dart might, in the near future, mean "works better on Chrome" rather than "targets the whole web", and because it means that Dart will work better with the universe of browser-targeted tools that aren't all written in Dart.
The VM is crossplatform and it even supports ARM and MIPS.
They are also working on an interpreter which will get around the JIT restrictions on iOS and Windows Phone.
- are much better than Dart,
- run in the browser and
- run on a crossplatform VM which is much better than DartVM?Well, its semi-useless enums suck, but other than that I'm quite happy with it.
As far as I can tell, the Dart team set out to create a clean slate approach to what web developers need in a language (front-end and on the server) to address today's complexities. What the Dart team couldn't foresee how many developers would come down with Stockholm syndrome regarding JavaScript.
What people don’t get: adding more crap to JavaScript doesn’t make things easier, it makes things more complex. Think about it: the entire web is depending on a language that was thrown together in like 10 days and renamed from LiveScript to it would contain the word 'Java' because Java was the new hotness back in the day even though it had nothing to do with Jsva.
And now we’re going to add all of the stuff we didn't think about back then when JavaScript was considered a weird, fringe toy language, when the most complex thing anyone did was image rollovers.
JavaScript didn't "win" because it was great; it won because it good enough and we were literally stuck with it.
Not everyone wants good enough; some people want an excellent, purpose built language for the web with all of the goodies we’ve come to expect on Day 1--no polyfills, no hacks, no waiting for a years long standards process to run its course.
I’m looking forward to the Dart conference next month to see what’s next: https://www.dartlang.org/events/2015/summit/.
Yes, absolutely; and Dart just doesn't fit that bill.
If there are so many, can you list at least 5 superior options for us please.
(Don't know that much about the others.)
Solid, mature, great libraries and one of the best languages out there, even when competing against real (in the sense of not compile-to-JavaScript-only) languages.
I haven't tried scala.js yet, but I've gone through some presentation slides...they're claiming compact code that runs as fast as javascript, clear error messages that point to the line of scala sourcecode, and even some advantages over jvm scala (though I forget the details). Don't know about compile speed.
I am somewhat sympathetic to what you are saying here. OTOH, the fact that the web is basically all one programming language[1] is a situation that I find a bit unfortunate. Why shouldn't the browser have a PL ecosystem as rich as the desktop? And why couldn't Dart be part of that?
[1] Yes, I know the world is full of compile-to-JS languages. But still, being a web developer today mostly means being a JS developer.
It's apparent that Javascript has taken cues from nearly every other modern programming language at this point. The leaps and bounds being made with ES6 and ES7 are simply astounding. Of course, I have no problem seeing the development of languages like Dart, Coffeescript, and Typescript that compile to javascript, but I think there's an argument to be made for the reduced need of these. The development effort being poured into them has shaped javascript, but I think what many people are realizing is that the focus doesn't need to be on creating new languages that compile to Javascript, when it can be on advancing Javascript even further.
I'm probably going to sound very negative in saying this, but I _really_ hate it when people pull this line out like it means anything. Only in the most narrow, trite sense is a programming language "just a tool." They are the whole reason programmers exist. Language is the single most important development in human history, and computers have touched human life in irreversible and undeniably important ways.
Everything is just a tool, if you look at it the right way, and it takes a particular kind of pointlessness to opt to see the world like that.
Language is the thing that makes the genie grant your wish. If you wish with the wrong words, you get a billion dollar tombstone.
Unless it turns out that JS+Flow is actually the best balance between flexibility and safety and the world will reach "singularity".
For example, here was my statement advising Discourse to avoid CoffeeScript in 2013: https://meta.discourse.org/t/is-it-better-for-discourse-to-u...
So I take it you write all your *nix programs in C?
That's the only sane answer if you have any intention of redistributing them.
So you think JavaScript is the best tool for the job? I don't think so.
Regardless, Dart is a great proof-of-concept for strong typing in a browser environment and I'm sure it helped renew faith in it after the disastrous results of the ES4 effort.
I would be interested in seeing Dart's approach to typing attempted as a layer on top of JS. Sort of a 'stronger' TypeScript where the compile pass enforces the kinds of type guarantees Dart provides, perhaps.
https://twitter.com/BrendanEich/status/308343704194781186
SIMD is in all the SoCs of course, which means it has been on JS stewards' radar for a while now (remember River Trail? see my blog post, which had early Dart humor and Dash-memo reaction: https://brendaneich.com/2011/09/capitoljs-rivertrail/).
I worked at MicroUnity from 1992-5 on many high-risk things including a new CPU that was designed to do extensive SIMD and bit-moving instructions; using these in an instruction-level simulator, I implemented 64-QAM demod and Reed-Solomon error correction for the cable-net of the day (TCL, remember them?). Alas the CPU design was unrealizable in hardware.
SIMD has been around quite a while in hardware, so as KGadd says intrinsics for it have shown up in major languages. It was only a matter of time and the right person for JS, and John McCutchan did the job. Thanks, John!
Google funded John's work for Dart and didn't keep him from doing JS uplift, so thanks to Google too.
"Just stop what you're doing" isn't helpful. People need to write code today, and we have solutions for them.
There is a difference between having innovators on a project versus maintainers.
Improving the web, in particular, requires that people think like maintainers and innovators.
That said, I also hope that they reevaluate their position in the world in a couple of years once Javascript has advanced down the road blazed by eg Dart and CoffeeScript.
[also, Dart can just be thought of as an abstraction for the language of JS, and what problem can't be solved by just another layer of abstraction? :P ]
Too many layers of abstraction. :P
A lot of the features of CoffeeScript are being integrated into JS with ES6 and ES7. The same is actually happening to the unique features of Dart such as typing and SIMD and better modules.
Typing is so cool: http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects
SIMD is amazing: https://github.com/johnmccutchan/ecmascript_simd
So, thank you Dart for showing us the way!
My only worry is that the innovators behind Dart are going to be stuck on the Dart project while JavaScript gains their features and even more momentum. I would suggest that they let Dart die and not be stuck with it for years after it has stopped being relevant -- that would be a waste of their talents as they did really see what the future would be.