The vocal portions of the Web that care about such things seem to have already made up their minds about Dart, the new web programming language from Google. My opinion of it has been flipping between intrigue and tedium.
Origins of Dart at Google
So they did just that. Sort of.
Dear Google, Public Relations != Developer Relations
Google suffers from NIH Syndrome: it does not take from the outside world, preferring to build its tools from scratch, and anything it produces it does so mainly for consumption by the thousands of people it employs (this manifests itself in things like their approach to Platform development, too). Don’t let the odd open-sourced project fool you.
In the case of Dart (not the first Google-made langauge) they may have hyped up its announcement, but they clearly have no intention of letting programmers — the only people who care — actually experiment with the new language yet. When you go to Dart’s code repository, there is little effort made to make it simple for you build and use anything.
Maybe Dart is just not ready for too much public airing, but that means they should have left its unveiling until it was. Google is not providing a pre-built compiler or VM binary for Dart, and their build instructions are just about tedious enough that I’d rather not waste my time. If
git clone and
make install are good enough for many a large project, why am I being instructed to install and use a Google-specific tool to merely fetch code?! No thanks.
What’s Dart Like?
Key Language Features
This is one of the more baffling features for me. You could write Dart code without any consideration for variable types, but you could also annotate your variables with types, like String or any class you’ve defined. The baffling nature of this is that the annotation is just that, an annotation: it makes no difference to how your code works, other than the compiler giving you a warning if you’ve misused the variable (e.g. tried to assign a number to a String variable). The code will still compile and run.
Structure and isolation
In the language specification, there is some detail about the concurrency model of Dart, which involves these isolates behaving like actors which perform local computation and then communicate via message-passing. I didn’t spend much time trying to understand these, but this (rather negative) write-up has an explanation.
Why you won’t use Dart
Firstly, there is obviously no practical implementation for developing or deploying Dart code, so don’t waste your time on it yet. Even the Google Chrome team aren’t 100% on whether and when they will implement a Dart runtime, let alone other browser vendors.
8 thoughts on “Dart: did Google miss the bull’s-eye?”
I think something more like a ‘running in a browser’ focused LLVM, with compiler/interpreter front end modules available, perhaps included with a <script interpreter=’http://www.ecmascript.org/v262/interpreter.module’ src=’test.js’ /> so that different language interpreters/compilers modules could be downloaded and cached.
Yep, I like the pluggable modules idea. Browsers have really good JS runtimes now, so I’m glad to see people like Mozilla are looking at including native CoffeeScript support as part of the development tools to build on top of that goodness. No-one cares how the final product is deployed as long as it works, and at the moment the JS engines work great, so I’d happily install a plugin for Firefox to develop in a JS-compiled languaged, debug away, and then ship a minified js file.
Of course, the danger of people treating JS as assembly (i.e. something they don’t need to learn) would be dangerous, but that’s a marketing/branding/education challenge.
 – https://wiki.mozilla.org/DevTools/Features/SourceMap
I’ve heard people much cleverer than me say that optional typing is ‘the best of both worlds’. You get dynamic (but strong) typing by default, which opens up a bunch of algorithms and approaches which just aren’t possible in a statically typed language. Then again, if you want to enforce a constraint like making a container homogeneous, or giving the JIT performance hints, which can make a substantial difference to performance, then you can.
I remember reading that post last year and at the time the commentary surrounding it suggested Yegge was actually talking about ECMAScript (Harmony? Maybe at the time of writing optional typing was on the table?). I think I’ll read through it again tonight, thanks for the link!
I agree with the opinion that optional strong typing is great. But Dart doesn’t do that. I like the way that Scala does it, with a proper type inference system, which enhances programmer happiness and productivity, whilst maintaining safety, whereas Dart’s offering is weak-typing, no inference and no prevention of runtime errors…!
By which I mean: http://steve-yegge.blogspot.com/2007/02/next-big-language.html
I read that again last night, and actually, yes Dart seems to meet most of the criteria Yegge mentions …!
So is this an honest review of Dart or are you trying to sell people on using CoffeScript which frankly doesn’t look like it adds much to js development other than saving a little bit of time typing? Unless I missed something is there any class/OOP implementation in CoffeScript?
No, not selling CoffeeScript, until the tooling is a lot better e.g. browser support for dev/debugging. But for side-projects I’d rather use CoffeeScript.
Important note, straight from http://coffeescript.org: