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 companies.)
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) parser.
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.