Yesterday (yes, Saturday!) the London Google Technology User
Group put on an all day session about the Go
programming language. Initially this was going to be a
90min talk followed by a "hack" session, but at the last minute it got turned
into an exercise-led tutorial. Andrew Gerrand (a member of the Go development
team within Google) led the session which had been organized by Anup Jadhav.
In effect this was a re-run of the session Russ Cox did at USENIX 2010
I think I would have started the session in a very different way to the way
Andrew did, but once things got going, it was a fun day. Certainly the guys I
ended up in the pub with were great. Bizarrely, the pub we had originally been
going to end up is was closed and shuttered. On a Saturday night, in a fairly
residential area. Anyway the place we ended up was OK, roomy enough, and the
London Pride wasn't too dreadful.
I have been looking at Go on and off for a few months now - I didn't look at
it immediately it was announced because of all the fanfare and hype, which was
reminiscent of the fanboi-ism rampant in the Apple product arena and now
spilling over into the Google product arena. However, once all the initial
fuss had died down, I started taking a look at it.
Go is marketed as a general purpose, statically typed, compiled to native code
programming language suitable for systems programming. It is aimed at the
place where C and C++ currently hold sway but bringing to that area some of
the "speedy development" aspects of Python, Java, etc.
I have to admit, as soon as I started using the language I liked it. I am not
keen on the massive fascism regarding code layout and the use of Make, but the
language is appealing enough functionally that I can get over this. I am not a
fan of the logo, mascot or even the language name, but can live with these -
mostly, trying to do Web searches for things associated with Go really is
hard. (Experience from Groovy indicates that programming languages with twee
names suffer a take up barrier, especially by the suits running most
The most obvious thing when you first see any Go code is that the types are on
the right of the names, Pascal style. Actually there is a really interesting
backdrop to token ordering in Go: Go can be parsed without performing symbol
table lookups. This enforces a left-to-right consistency of all tokens making
complex type specifications readable. Contrast this with C and C++ where some
type specification are literally incomprehensible unless you are an LL(k)
What I like most about Go is the goroutines - though again I don't think the
name is anything other than a twee joke. Go recognizes that the Multicore
Revolution is in full swing (unlike C++ which is only just getting to the
"threads are part of the language" stage of development): Go has a high-level,
very usable model of concurrency based on processes and channels - threads are
infrastructure the programmer should never have to work with.
Go's antecedents are the AT&T series of languages associated with the Plan 9
operating system. Process and channel based thinking has been an integral part
of this development from the outset. Newsqueak led to Alef which led to Limbo
which led to Go, this has been positively confirmed by Rob Pike on the Go
users mailing list:
_ Russ's [Russ Cox] historical analysis is right, except that there were two
CSPs. The original 1978 paper did not have channels; the later book did.
Newsqueak was the first programming language I ever used that had channels,
but that is not a claim of invention. I honestly have no memory of where idea
for channels in Newsqueak came from, but I'm pretty sure I didn't see the CSP
book until afterwards. I do have a vivid memory of getting the idea for the
implementation of hyperthreading in Newsqueak by generalizing something I read
in the HUB paper by O'Dell, which was based on much earlier work by Masamoto;
that was the trigger to write the language. Winterbottom grafted Newsqueak's
communication ideas onto a C-like systems language to create Alef. Limbo
arrived when it was time to build a virtual machine for embedded processing. _
_ Neither Occam nor Erlang influenced those languages. I didn't learn much
about Occam until after Newqueak, and about Erlang until after Limbo. It was a
long time ago but I believe I ignored Occam primarily because of its lack of
first-class channels; its roots in hardware did not enable that generality. _
So the process and channel approach of Go is a different thread of development
compared to Erlang, Scala, Python-CSP, GroovyCSP, etc. yet leading to exactly
the same paradigm, a paradigm yet to have impact in the C, C++, Fortran and
Java communities. This software architecture paradigm fits superbly with
massively multicore processors predicted for the medium and long term.
Contrast this with the shared memory multi-threading paradigm which is
increasingly causing problems for C, C++, Fortran and Java code.
Most of yesterday's session was about Web applications - not really surprising
given that the session was led by Google - and didn't really cover the package
structuring, code testing and parallelism aspects of things, which for me are
the unique selling points (USPs) of Go. I think Go will rapidly replace C for
all software development that uses C because it is the default language of
development. I suspect C++ will lose some to Go, but C++ has capabilities and
a fanatically loyal user base that more or less guarantee it will still be
used for many years to come. Also some applications using Python (and Ruby,
Perl, etc.) will use Go because it has many of the ease of development aspects
that these languages have but it is compiled to native code and so very much
faster of execution. Python (and Ruby, Perl, etc.) are of course dynamic
languages and so have meta-object protocol capabilities that are impossible
with compiled languages such as Go, C, C++, Fortran. Though, like Java, Go has
a reflection system.
But Go is just a Google language the purpose of which to promote the monopoly
of Google over everything in everyone's lives. I hear you say. Well it is
true that Go is currently being developed by Google staff with an eye to
Google's use, but it is an open source project in the full FSF definition.
Go is still a very young language, but the libraries are being built at a
fairly astonishing rate. It will very soon be ready for production code usage
by all and sundry.