Why Go Matters
2009 November 13
by avdi


This week Google announced a new systems programming language called �Go�. I know you�re pressed for time and overloaded with information, so let me restate that, with the important bits emphasized: Google announced a new SYSTEMS programming language. See that word between �new� and �programming�? The systems part seems to have gotten lost in a lot of the Twitter and blog buzz, despite the fact that it�s featured prominently at the top of the Go home page.

What�s a systems programming language? It�s the kind of language you use when writing a new OS. Or a device driver. Or an I/O stack. Or a piece of networking middleware. Or a very fast web server.

What does this mean? Go is not going to replace Python, or Ruby, or Scala, or Closure, or Objective C, or Erlang. Well, maybe Erlang. Go is more properly compared to languages like C, C++, D, ooc, and to a lesser extent Java and C#. Please stop Twittering about how #golang is [better|worse] than Python or Ruby. Different niches, different tools.

Why does it matter? When I got into programming, if you wanted to do some systems programming you had two choices: C or C++. Ten years later, you still have the same two choices. There has been an explosion in viable high-level languages for applications programming. But if I want to write, say, a new high-performance SPDY web server, my choices have not changed. Yes, there has been some work in applying functional languages such as haskell and O�caml to this problem space, but if I want wide platform support and a strong developer community it�s still C or C++.

Why is Go likely to succeed where others have failed? First, paternity. Go counts Ken Thompson and Rob Pike among it�s creators. If the significance of that fact is not immediately obvious, Google them. I�ll wait.

Second, it has Google behind it. C++ succeeded so well because it had AT&T behind it, building large systems with it, refining it, and advocating for it. Google has the size and clout to make Go more than another research language.

Is this a good thing? I don�t know yet. But � and I say this as one of those rare nutcases who actually likes C++ � I look forward to having options other than C++0x next time I have a systems programming problem to solve.

UPDATE: What about Erlang? I haven�t used Erlang yet, but I�ll go out on a limb a little and say that Go vs. Erlang is another false comparison. Yes, both languages directly address concurrency. But Erlang was designed in an era before multicore processors. It�s concurrency facilities are built with distributed computing in mind, and it sacrifices some low-level efficiency in order to make distributed operations transparent. As far as I can tell Go�s concurrency primitives do not address distributed computing at all, and are instead focussed on fine-grained multiprocessing on a single machine. In this regard Go is probably more comparable to Clojure.

That isn�t to say that Go is no threat to Erlang; but it seems to me there they occupy somewhat different niches.