Category Archives: Google

See Dart … Java?

About a month ago, Google made headlines when an email describing ambitious plans to re-create JavaScript was leaked to the web. This email created quite a stir and spawned numerous debates ranging from the hubris of Google in trying to single-handedly replace such a ubiquitous staple of the web to the possible merits of Google’s decision on a technical level and the kinds of exciting innovations that could occur.

While I personally didn’t feel great about Google’s actions, I decided to reserve my public judgement for the time when Google actually released the language. Two days ago, that finally happened. So, let’s take a look:

main() {
  print('Hello, Dart!');
}

Ummm … ok. This chunk of code looks similar to JavaScript, so that’s not all bad. However, I was really expecting something more groundbreaking in terms of syntax. While I don’t loath semi-colons as line endings (you have to have something, right?) the new trend these days is to exclude them. Specifically coming from a JVM perspective Scala, Groovy and Clojure, three of the most popular Java alternatives, are happily semi-colonless. Also, as Google has deep Python roots, I expected they’d create something with a more “modern” syntax. But that’s ok … I can live with semi-colons. Let’s dig a bit through the Dart sample source code (can currently be found on Dart’s Google code page).

Check out https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/client/samples/swarm/BiIterator.dart (I’ve removed the comments for brevity):

class BiIterator<E> {
  ObservableValue<int> currentIndex;

  List<E> list;

  BiIterator(this.list, [List<ChangeListener> oldListeners = null]): currentIndex = new ObservableValue<int>(0) {
    if (oldListeners != null) {
      currentIndex.listeners = oldListeners;
    }
  }
  E next() {
    if (currentIndex.value < list.length - 1) {
      currentIndex.value += 1;
    }
    return list[currentIndex.value];
  }

  E get current() {
    return list[currentIndex.value];
  }

  E previous() {
    if (currentIndex.value > 0) {
      currentIndex.value -= 1;
    }
    return list[currentIndex.value];
  }

  void jumpToValue(E val) {
    for (int i = 0; i < list.length; i++) {
      if (list[i] === val) {
        currentIndex.value = i;
        break;
      }
    }
  }
}

When I first saw this code, I instantly recognized a very similar syntax to Java 5 generics. Eerily similar, in fact. As powerful as Java generics are, not too many people like the syntax. To port what many consider to be kruft to a brand new language is an odd choice.

Another interesting thing about this code is the inclusion of strict comparison operators (i.e. ‘===’ and ‘!==’, see line 31 for an example). While the use of these operators is instantly recognizable to those of us who regularly use JavaScript, I think it a very odd decision to include these operators in a brand new language. They are, essentially, a JavaScript oddity that often confuses people when they first learn the language.

So far, things aren’t looking great for Dart.

There is hope, however: Dart has great support for concurrency. It implements a version of the Actor model (see http://www.replicator.org/content/a-first-look-at-dart-the-programming-language for details) placing code into Web Workers behind the abstraction. Concurrency is rarely easy and the Actor model is a great way to abstract that kind of complexity away from the developer.

So, let’s take a look at a basic Actor (Dart’s interface is called an Isolate):

class Printer extends Isolate {
  main() {
    port.receive((message, replyTo) {
      if (message == null) port.close();
      else print(message);
    });
  }
}

main() {
  new Printer().spawn().then((port) {
    for (var message in ['Hello', 'from', 'other', 'isolate']) {
      port.send(message);  
    }
    port.send(null);
  });

Huh. It doesn’t look terrible, but I’ve been doing a lot of Scala development recently and Scala also happens to have actors. Let’s take a quick look at how Scala might implement the above code:

import scala.actors.Actor._ 
val portActor = actor {
    while (true) {
        receive {
            case msg => println(msg)
        }
    }
}
List("Hello", "from", "other", "actor").foreach( word => portActor ! word)

Granted: these are both contrived examples. However, look at the Scala version. It’s doing some tricks like importing a static Actor but it is still, at least to my eyes, much more readable and elegant than the Dart version. While it’s nice to have an actor-based model for client development, I feel like Dart’s falls short in comparison to Scala’s state of the art implementation. Again, considering this is a brand new language, this is puzzling.

Finally, Dart itself can either be executed in a virtual machine or transpiled to JavaScript for execution in a browser. Since most browsers outside of Chrome won’t have much support for a native Dart VM in the near future, let’s take a look at Dart’s transpiling overhead. This is probably all you need: https://gist.github.com/1277224. Dart’s ‘Hello World’ application transpiled to over 17,000 lines of JavaScript. Wow. To be fair, this overhead has to do with setting up Dart’s optional typing system and other niceties of the language which is more akin to including a library. As such, this isn’t an apples-to-apples comparison with JavaScript itself or something like CoffeeScript which transpiles in a more one-to-one fashion.

But still. Wow.

So, at least for now, it seems like Dart is a bit of a snooze. As much as I was disappointed in Google with not being more open about the development of Dart, I was also excited in seeing something that would simply blow away JavaScript and set the stage for something ground-breaking (maybe something like “ScalaScript”). Dart is not that. Core Java developers will likely feel right at home with Dart, but I can’t see the huge community of client-side JavaScript engineers being very excited about this.

Dart, I am disappoint.

My Google Experience

I suppose it’s some sort of “rite of passage”, but I got pinged from Google about a month ago for a possible job opening. A Google recruiter came across my blog (very likely what you’re reading now) and thought my credentials and experience might be a good fit for a position at the office in Boulder, CO (that office, as far as I can tell, is mainly responsible for the Google Docs suite of products). While I’m pretty happy where I am, I felt very flattered they would feel that I could be a good candidate at a company whose hiring standards are the things of engineering lore.

The recruiter asked my permission to apply for the position, and the next email I received was that one of the senior engineers was interested in having a phone interview with me.

Let me back up and say that I was not sure what to expect. In my day-to-day projects, including those both both work-related and “for fun”, I typically spend more time playing with the latest technology than thinking about things like the efficiency of the Java Collections library. In other words, I’m very much a pragmatist rather than a theorist in most cases.

However, I decided to look at this opportunity, however it turned out, as an excuse to improve my theoretical skills and advance my effectiveness overall as an engineer. To that end, I delved back into discrete mathematics, algorithm analysis, concurrency issues, and overall performance making a conscious attempt to look at problems more like Google might (on a super-large scale).

I’ll talk about the actual interview below, but just the process of prepping for the experience was a huge boon, I believe, to my individual development as an engineer. In fact, I had such a good experience revisiting these topics that I have decided to both continue the process as well as begin looking towards starting a graduate degree later this year.

The interview itself went fairly well. As far as advice goes, I’d recommend anyone attempting to interview with Google refresh their algorithm analysis knowledge as well as spend some time on the more esoteric features of the platform/language in question. I had a question about Java inheritance which I answered incorrectly (I realized after the fact when I tried the scenario) simply because I rarely use inheritance in my day-to-day engineering (I prefer composition in most cases these days). However, I think my answer to the algorithm analysis question was pretty spot on albeit taking probably more time than I should have getting my head around the problem.

Despite not being picked up for the position, I’m still flattered that, less than two years after receiving my CS degree, I am getting interest from a company known for hiring only the best. It makes me believe that my career is on a good trajectory and gives me even more to look forward to in the future.