Why Go Matters

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.

20 comments

  1. Hey there – interesting article. I'd like to make a few points, though:

    – history has shown a language doesn't need a huge company behind it to be successful. C and Python (among other) have spread grassroots-style and we can see the result today.

    – what exactly makes you say Go is “better” than ooc? (and other cited languages)

    – also, since when is it meaningful to say a language is “better” or “worse” than another? only trolls do that. Please, rather make a list of the differences! Enlighten the general public about what they're best used for – different niches, you said so yourself.

    – one last thing: please, please stop over-hyping all of go features. Have you guys been detained in C++-only prisons for the last 30 years or what? ooc has coroutines too http://bit.ly/1vAg3I (a lot of languages have) and you can also use coroutines from regular C and C++, just Google it

    – finally, although I can't bear its syntax, Go has indeed a lot of interesting things under the hood, such as its GC (which afaik isn't inheritent to the language, so could be used e.g. for ooc), and yes, the fast compilation times.

    That said – it's great seeing interesting languages pop out. I've always been and always will be for diversity.

    As for ooc, I'm quietly developing my own tools – and seeing a small community growing slowly around it. This is more than what I'm asking for, thanks everyone for being a part of it =)

    There's no competition here: stop faking it.

    1. Go is better compared to languages like C, C++, D, ooc, and to a lesser extent Java and C#.

      He never said “Go is better”. He said “Go is better compared” As in, it's best/more accurate to compare it to C, C++, D and ooc than it is to compare it to Ruby and Python.

    2. I think you misread the article. I never said that Go was better than ooc. I said “go is better compared to languages like…”. That means that it is better to compare it to those languages than to languages like Ruby and Python. I can see how if you were reading fast, or if English is not your first language, you might have misinterpreted it to mean I was saying that Go is better than other langauges; but that was not the intent.

    3. I reworded the statement in case others made the same mistake.

      By the way, I disagree with you in one regard: of course there is competition. There is always competition in a healthy language ecosystem. It may be of the friendly and mutually beneficial sort, but languages will always compete for mindshare. I for one am happy to see competition returning to the systems language arena, in the form of languages such as ooc, Go, and D.

      1. Well yeah – there is that kind of competition, which is indeed healthy =). What I was saying was in reaction to “x, y, and z are competing for the title of 'better language'”, which was the result of a miscomprehension from my part =)

        Thanks for clearing up those issues for me, and reacting in a good way =) This is rare enough (for coders in general) to be pointed out.

  2. Please stop referring to it as “Go”, or as a courtesy to the developer of the original “Go!” language, put a disclaimer up top. It is just Unfortunate that developers keep perpetuating Google's mistake by calling it Go without acknowledging the controversy surrounding the name of the language.

  3. It's hard to say Erlang could be replaced by Go, given Erlang has reliability and fault-tolerance in mind, with advanced ways to do error management like supervisors, while Go doesn't even have exceptions, live code upgrades, distribution, etc.

    Erlang is also an environment: you've got tools letting you manage the VM's processes (like etop, which is unix's top for Erlang), connect to remote shells, the OTP framework, profilers, loggers, Dialyzer, etc.

    On the other hand, Go has very interesting concepts that are not part of Erlang, such as their implementation of interface types that turn out to be a bit like compiler-checked duck typing [from what I understand]. Go is also supposed to be much faster than Erlang, although this should be no secret.

    This is not to say Go can't be used to make reliable stuff, but it's going in a pretty different direction than where Erlang is going. Those who consider Go and Erlang to be competitors seem to be those who reduce Erlang to 'a language that does lots of concurrent stuff' and not much more. The reduction is understandable, but it misses a lot of what's important.

    1. For the record, I agree about the differences between Go and Erlang. I just won't be suprised to see people applying Go to some of the same problems people are currently applying Erlang to, as the language matures. And for better or for worse, languages with C-based syntax always have a leg-up when it comes to developer adoption.

  4. There's a problem, though — Go is slow. Like, an order of magnitude slower than Scala. Like, about half the speed of V8.

    That's not exactly the tool I'm going to reach for when I'm implementing a fast web server, especially if I have to give up all the cool features that languages like Scala have.

    1. Of all the valid criticisms of Go I don't find this one particularly convincing. Sure it's slow right now. It's immature. But having taken a look at the language I think it's very amenable to optimisation, at least as much so as Scala and definitely more so than JavaScript. Considering Google's need for speed – there's a reason they do more C++ coding than most web-focused companies – I think we'll see Go become a serious contender in short order.

      1. It'll definitely improve, I agree, but I'm much more pessimistic about the rate of approval, mainly because I think people are overestimating Google's internal support for Go. The most that's been publicly said about internal adoption is that they have some cool demos, and that while it's not ready for production, it's getting there. Their GCC compiler doesn't even implement garbage collection yet, to give you an idea of how far there is to go.

        In contrast, V8 is a core component of Google's official browser (itself soon to be the core component of their official operating system), and has been tasked with quickly and efficiently executing the heaps of Javascript that Google's user-facing applications are built from. I would say that falls squarely under “need for speed,” and the regular drumbeat of V8 releases and improvements speaks for itself.

        So the amenability of a language to optimization has to tempered by the amount of resources put towards that optimization. Until I see evidence that Go is moving at a faster clip than, say, Simple (their BASIC-for-Android lang they released this summer) I'm going to consider it someone's 20% project.

  5. Also, the Erlang virtual machine has long had the feature of concurrency on multicore systems.

    Also, what 'n ddrylliog said about C isn't necessarily true – it -did- have a large company behind it, Bell Labs, which at some point was or is a branch of At&t.

  6. Also, the Erlang virtual machine has long had the feature of concurrency on multicore systems.

    Also, what 'n ddrylliog said about C isn't necessarily true – it -did- have a large company behind it, Bell Labs, which at some point was or is a branch of At&t.

Leave a Reply to 'n ddrylliog Cancel reply

Your email address will not be published. Required fields are marked *