A first look at Dart

Google released details about the Dart language today, and I am surprised how much more it is like Java than like JavaScript.

I had expected a prototype-based language, either a streamlined JavaScript (boring) or something like Newspeak (interesting). The latter seemed plausible because Gilad Bracha is on the Dart team. But it's very Java-like, with optional typing.

class BankAccount {
  var _balance; // _ before field name makes it private
  BankAccount(this._balance); // short form for boilerplate constructor
  deposit(amount) { _balance += amount; } // no param, return types
  withdraw(amount) { _balance -= amount; } // automatically public
  get balance() => _balance; // property getter
}

main() {
  BankAccount acct = new BankAccount(1000); // var acct = ... also ok
  acct.deposit(100);
  acct.withdraw(500);
  print("balance: ${acct.balance}"); // string interpolation
}

Unlike Scala, it's not an expression-oriented language, but if a method merely returns the value of an expression, you can replace foo(args) { return expr; } with foo(args) => expr;

(Yes, that semicolon is required. This isn't JavaScript.)

Like in JavaScript, we have closures.

main() {
  var balance = 0;

  deposit(amount) { balance += amount; } // Updates variable from enclosing scope
  var withdraw = (amount) { balance -= amount; }; // Function literal
  
  deposit(1000);
  withdraw(100);

  print(balance);
}

There are interfaces, just like in Java. Interfaces declare abstract methods, setters and getters, and factories.

interface Account factory BankAccount {
  Account(balance); // The factory class must supply such a constructor
  get balance();
}

class BankAccount implements Account {
  var _balance; 
  BankAccount(this._balance); // Here it is
  get balance() => _balance; 
}

main() {
  var acct = new Account(1000); // Constructs a BankAccount
  print("balance: ${acct.balance}");
}

There are generics, but the type parameters aren't taken very seriously.

main() {
  List<String> names = new List<String>();
  names.add("Fred");   
  List<Object> objects = names; // This would not work in Java or Scala
  objects.add(new Date.now()); 
  print(names[1]); // Now names has something that's not a string
  print(names[1].length()); // A runtime error 
}

Technically, all type parameters are covariant. Scala programmers would wince—they except the static type system to catch errors such as this one. Of course, there is a price to pay—variance annotations,  wildcards, type bounds.

There is a tiny library, but you can't get at the library source from the documentation. This isn't Scala or Ruby. Get the source from here.

Who needs that clunker? The stated goal was to have an alternative to JavaScript, with a more perfomant VM. Apparently, there are currently roadblocks in efficiently compiling JavaScript. (Dart can also be compiled into JavaScript, but that seems more of an interim solution, until that happy time when every browser has a Dart VM.)

Will web programmers give up years of experience with JavaScript for another language, just because it compiles better or scales to larger projects? Probably not anytime soon, and Google knows that. These people think that Dart will be the new vehicle for GWT. I suppose GWT is important, but is it that important?

That's where the poison dart conspiracy comes in. Where could a shiny new language and VM be required? There is that other Google toolkit that doesn't run on the web but on devices that are connected to the web. Right now we program them in Java—familiar old Java, but with a different UI toolkit and a different VM. That may not always be the case.

When I first heard this, I wasn't so sure, but now that I had a glimpse at the language, I agree that Dart would make a perfectly good language for Android. Maybe it will be used for web and mobile programming. Google would like that. For us Java developers, it would not be such a happy development—another nail in the coffin of mobile Java.