Throwing Darts

A few days ago I talked about Dart and Javascript and the features of Dart that the web desperately needs. I did not say much about Dart as a language, or whether I believe Dart is going to make it or not. I’d like to elaborate a bit on that now.

I would like Dart to succeed, let me start with give a few reasons why.

First and foremost are the reasons I mentioned previously: Dart provides a few vital features that the web needs:

  1. Built-in support for modules.
  2. A clear and unambiguous OOP story.
  3. An extensive library of APIs you commonly need, so there’s no need to reinvent the wheel every time.
  4. A declarative way of specifying project dependencies and a package manager to manage them.

I know, JS.next — whenever it will be available in a browser near you — will give us modules and classes. That’s a good thing.

Second is a reason that’s usually used against Dart: Dart is boring. It’s uninspired. There’s isn’t much new there. It takes ideas from other languages that have been around for decades and remixes them.

I think that’s a good approach. The process of creating a language that is to be used by millions is a pretty bad time to experiment with crazy new language ideas. Chances are that those nifty features will blow up in your face.

There’s always a degree of failure when you attempt this. Java brought a lot of good things to the mainstream, including garbage collection and fast JIT VMs. But other things failed, specifically checked exceptions. Brendan Eich decided to put quite some nifty features in Javascript back in the day. Many worked well — Javascript is not a bad language — but guess what, some turned out to be pretty bad ideas too.

Dart takes features used for decades: modules, classes with single inheritance, lexical scoping, function closures and isolates (similar to actors in Erlang) and mixes them together in good-ol’ curly-braced dynamic language.

Dart has one experimental feature, however: an optional and unsound type system. This is a controversial idea. I have at least one colleague who think it’s insane to design a language this way.

Dart is a dynamically typed language, but it does allow you to add type information — for instance to variables, or function arguments. Both of the following are allowed, and as far as the runtime is concerned, are equivalent:

sayHello(name) {
   print("Hello $name!");
}

and

void sayHello(String name) {
   print("Hello $name!");
}

The thinking behind this is that you may want to start out writing your code without types while you’re still exploring how you want your program to work, without wasting too many finger and brain cycles on getting the types right. Later, when the code is more mature, you can annotate it with types for documentation and tooling purposes. You can run your program with runtime type checking on (if so, it will fail when you pass in arguments of the wrong type), or in production mode without any run-time type checking. Type annotations are not safe enough to be used to optimize the code in the Dart VM — the VM treats it as a fully dynamic language and ignores the type information. The current dart2js compiler, however, does appear to use type annotations to generate more optimal Javascript.

Conceptually I like the idea of optional types, but it’s a “new” feature, it could turn out to be a horrible idea. It’s a risk.

The third reason I like Dart is its support for structured programming. As mentioned, Dart supports modules and classes natively. You can ignore it all you want, but most large Javascript code bases use some way to encode classes and inheritance. Dart, like Java, and Ruby, and Python, and C#, and C++ supports this at a language level. I think that’s a good thing.

Prototypes are a nice idea, but they may just be too powerful for many people to handle, class based object-oriented programming is simple and powerful enough.

And modules… well, you need modules. You need them to be part of your language.

All in all, I think Dart is a better language than Javascript — so I’d like it to succeed.

The question is: will it succeed? Sadly, I’m all but convinced.

One big roadblock is politics. Brendan Eich, CTO of Mozilla (and inventor of Javascript) has said:

[…] Yet I guarantee you that Apple and Microsoft (and Opera and Mozilla, but the first two are enough) will never embed the Dart VM.

Other browser vendors don’t like the fact that Google went rogue on them and developed a whole new language by themselves. Personally, I’d argue this is the only way to get to something better — all the compromising hasn’t sped up the development of Javascript, nor has it led to a prettier language.

In response to my previous article, people have told me Dart is bad because it is “proprietary”. That does not make much sense, since Dart is BSD licensed and can be embedded in any browser. If Chrome were the only browser to adopt it, that’s the choice of other browser vendors. What people probably mean with “proprietary” it’s not an agreed upon and standardized like Javascript. Javascript by now has been blessed as the scripting language of the web — it is the standard, it’s in W3C documents and everything.

Now, I may be getting my history wrong, but I’m pretty sure that Javascript in the 90s started its life much more “proprietary” than Dart is today. It was a completely proprietary language, unique to the commercially licensed Netscape browser. It was later reverse engineered and copied by other browser vendors. Google from the outset has said that Dart will be open source and they wish to standardize the language once they have matured it.

A second big problem that I foresee for Dart is Google itself.

Google develops products like I threw darts when I was a kid: grab a bunch of darts and throw them full force in the general direction of the target to see what you hit.

If Google would go all-in on Dart, I’d be more convinced, but Google has many competing front-end developer technologies:

  1. Google Web Toolkit
  2. Closure compiler and library
  3. AngularJS
  4. Native client

All of these have slightly different audiences and use cases, but many of them are bound to be canned at some point. Google Web Toolkit is practically dead already.

In Google’s company culture, each team can choose its own tools. There is no top-down policy on these matters. That means that the Google Closure team is competing with the Dart and AngularJS teams trying convince developers internally to use the tools they develop. If none of the teams within Google would adopt Dart, would they can the project?

I should ote that Dart is still in a preview state. Google itself doesn’t even recommend you use it for more than just playing. Once there’s a 1.0, we’ll have to see what happens.

Is LogicBlox going to write its applications in Dart? We already had our fair share of buying into languages that didn’t make it long-term. You have to pick your battles. Strategically it does not seem very wise to buy into Dart right now. I hope that day will come, though.

If only Google would stop throwing darts.