The Go Language

Posted on 2009-11-22 by Curt Sampson :: comments enabled

Francois Berenger recently brought to my attention a relatively new systems programming language called Go, a project started a couple of years ago by Robert Griesemer, Rob Pike and Ken Thompson. With luminaries like this designing it, this is certainly going to be something to keep an eye on.

It’s got a somewhat C- or Java-like feel, but tries to give the ease of programming you get from Ruby or Python. As they say in the FAQ:

Go is an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language. It also aims to be modern, with support for networked and multicore computing. Finally, it is intended to be fast: it should take at most a few seconds to build a large executable on a single computer.

At a brief glance, the type system is interesting, and seems to take some ideas from Haskell. It’s not object-oriented, but what one might call interface-oriented, sounding very much like Haskell’s type classes:

Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods. Besides reducing the bookkeeping, this approach has real advantages. Types can satisfy many interfaces at once, without the complexities of traditional multiple inheritance. Interfaces can be very lightweight—having one or even zero methods in an interface can express useful concepts. Interfaces can be added after the fact if a new idea comes along or for testing—without annotating the original types. Because there are no explicit relationships between types and interfaces, there is no type hierarchy to manage or discuss.

The effect of lack of inheritance, as compared to Haskell’s type class system, will be interesting. Haskell, in practice, doesn’t use inheritance everywhere it should anyway (an instance of Monad, for example, is not required to be also an instance of Functor, though this is widely regarded as a design defect) and yet it gets along ok.

Additionally, just like Haskell, it allows neither overloading of function names nor implicit numeric conversions. These two decisions I anticipate will meet with objections from users of languages such as Ruby and Python (I didn’t like these myself when I first started using Haskell), but my experience with Haskell over the last year or two has shown me that they are the right choice.

I wonder if they got rid of the dreaded “null reference,” though.

Speaking of Tony Hoare, Go’s support for multicore computing is based around his Communicating Sequential Processes, in the spirit of Erlang. It would be interesting to do a serious comparison of how this compares to purity when trying to gain parallelism.

It will be interesting to see how Go compares to Haskell as a systems programming language. Right now Go is missing some key FFI (Foreign Function Interface) functionality, such as the ability to allow other code to call into Go libraries, that is present in Haskell FFI (at least in the GHC implementation). But once all of that’s there, given that Go will also have a runtime system (albeit probably more light-weight than GHC’s), what will be significantly more difficult or impossible to do in Haskell that can be done easily in Go?

There’s a discussion group, golang-nuts, on Google groups.


By Keith Sheppard on 2009-11-22 04:54:18 UTC:

First off I think go is really cool and has some great features for a systems language, but I did find a couple of disappointments.

I wonder if they got rid of the dreaded “null reference,” though.

They did not. There is a long discussion on this on go-nuts “Repeating the Billion Dollar Mistake”.

Also where Haskell allows you to extend types outside of the module definition by adding class instances this isn’t possible in go. Of course this doesn’t matter much when you’re writing your own modules but I think it’s going to become more of a problem when libraries are developed and used more widely. This comes up in the “Type System not Uniform” thread.


By Daniel Lyons on 2009-11-22 05:54:03 UTC:

Hi Curt,

I just read your excellent analysis of Go, via a link to the Go mailing list. The type system similarity to Haskell also caught my attention. I don’t think they borrowed much from Haskell but this is a very interesting choice, IMO. What they’re calling type inferencing is much more limited than what we as functional programmers are accustomed to, though still a marked improvement in the procedural/OO world.

They did, however, retain the null reference. The designers apparently didn’t feel that this was a big problem, though it has been discussed at some length on the mailing list. Apart from that, most of the complaints have to do with the lack of generics or exceptions, the former leading the latter somewhat.

I have written a somewhat lengthy analysis myself, if you are curious about it:


More than anything, I’m pleased to see a language this well constructed. And I think the death knell for closureless languages has officially been sounded. Now to get continuations sorted out… ;)

Thanks for the excellent article!

Add a comment »
comments are moderated