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.