A Brief, Personal View of Go

Boyko Bantchev  //  November 2009

What the Fuss Is about

Recently, Google presented its new programming language, Go, and declared it open-source.

Go is meant to be a small and simple systems programming language, safer than C, and allowing for short development times. Go programs compile very fast, themselves being ‘typically 10-20% slower than C’. The authors also say that Go is very productive to write in.

Of course, the great interest that is being generated around Go has to do, for now at least, not so much with the language itself as with who is behind it. It is not ‘just’ the giant Google corporation; Go is designed and helped being implemented by a bunch of persons of immense prestige in programmerhood.

Listed as principle designers are Robert Griesemer, Rob(bert) Pike and Ken(neth) Thompson. Thompson is the one who created the very initial Unix, co-created Plan 9, and wrote numerous programs for them that are used worldwide. Pike was also a member of the great Unix team (although, being somewhat younger, he came to it later), was deeply involved in the creation of Plan 9, Inferno and the Limbo programming language, and is widely known as a co-author of books with Brian Kernighan. Of Griesemer I knew nothing, but a short Internet search revealed that he was a student of Niklaus Wirth – the prominent computing pioneer and creator of Algol W (with C.A.R. Hoare), Pascal, Modula, and the Oberon language and operating system.

Ian Taylor, of GCC's autotools fame, and Russ Cox, well known in the Plan 9/Inferno community, are said to have helped, in a way or another, in implementing Go.

*   *   *

So I was, very naturally, curious about what the new language is like. I read some of Go's definition, the FAQs, other documents, even watched the video, trying to extract not only what the language authors are willing to tell us but also what they omit, deliberately or not. Here is a summary of my findings, mainly centred around the facets of Go that make it different from C, and grouped in decreasing order of my liking them. I am just listing these, with almost no commenting.

I wrote all of this down because I thought other programmers might by interested in comparing Go to C without having to read too much of the official documentation. This includes myself, in a couple of weeks from now.

Things I Like

Elements of Go to which I Am Indifferent

These may be good or not. I have no definite opinion on the value of any of them.

Bits I Find Mildly Annoying

Things I Dislike

Frankly, the ++/-- issue alone is enough to make me avoid this language if possible. Sheer ugliness!

And here is why I am finding Go's declaration syntax unattractive. They took from Pascal/Modula/Oberon the rule to write down variable names before types, but did not adopt the colon, and added the Algol 68 style of backward array type definition (e.g. []int). The resulting mix is uglier than any of the mentioned languages, and perhaps worse than C. Had they borrowed from only one of these languages (or from D, for that matter), the result would have been much better.

In Pascal or any of its descendants we write i: integer, whereas in Go it is i int. The latter is simpler, when taken in isolation, but consider a procedure header such as proc(a int, b, c float). With the colons retained, it would have been proc(a:int, b, c:float). Even better it is in the C/D style – proc(int a, float b,c) – and perhaps still better is proc(int a; float b,c). Any of these variants is better readable than the one implemented in Go.

I personally conceive of type names as similar to monadic operators, and therefore int i is preferable to me than i int. But more importantly, the syntax of a language should make program parts easily discernable. Go's variable declaration doesn't.

Go-ing political

There are several issues of political nature with Go.

The Go authors say, in the FAQ, that ‘no major systems language has emerged in over a decade’. ‘Arguably longer’, adds Pike in his live presentation. Well, there is certainly at least one such language, D. By all measures it can be considered ‘major’, unless someone proclaimed a new meaning of the word. It is hard to believe that the sages are so uninformed as not to have heard of D. There must be another reason why they ignore D's existence. (Hint: there is a significant overlap between the publicly stated goals of Go and those of D, and D is widely considered a good design.) My guess would be that Google is after catching the attention of the open source community, as that community can greatly contribute to Google's success in whatever the company is seeking. In the game of winning hearts and minds D might be a rival.

The very name of the language is an issue. It clashes with the name of Go!: another language with similar goals (but much more different from C), introduced in 2003. Go!'s author requires that Google change the name of their language. I am unaware of how widely Go! is being used, but there is a published book on it. And again, it is hardly the case that nobody in Google knew about Go!. If they knew, why did they act as if they didn't?

And finally, the language Oberon and N. Wirth should have been acknowledged by Go's authors much more explicitly than with the single phrase ‘… significant input from the Pascal/Modula/Oberon family’ in the FAQ. As already mentioned, from Oberon Go borrowed the concept of extensible structs, as well as its attachable procedures. In view of Oberon having already, and for quite some time now, proven successful as systems programming language, the features now copied to Go are of great advantage to the latter. How come their inventor is not even mentioned?


Go may turn to be a useful and successful language. Or not. These things are impossible to predict.

Do I like Go? I do like some of its features, and I remain curious of how much I would like the exeperience if I program in it something not completely trivial.

But I know I am not going to love Go. True beauty evades this language. Go may be practical, but is also eclectic, and has taken some unconvincing or downright ugly design choices. It definitely lacks that subtle but unmistakable touch of elegance that makes a language great.