Why Google's Go is a Bore

Summary

Here's my TL;DR summary of the following long rant: Google's Go programming language is a boring entry in the world of programming that got undeserved buzz only because of some names attached to it.

Preamble

There's been a lot of buzz lately around the new programming language from Google: Go. It gets this buzz primarily because of the names attached to the project, to wit:

Rob Pike's name attracts attention because of his attachment to the undeservedly successful UNIX virus over thirty years ago. He's also one of the principles behind the UTF-8 encoding scheme. That's about it for major accomplishments. His name is otherwise attached to the much-admired but little-used Plan 9 and Inferno operating systems and the attendant language for the latter, Limbo.

Ken Thompson is known for the C precursor language B plus his major contributions to the UNIX virus and to Plan 9.

Now, some of the deprecating language aside (I just think UNIX is vastly overrated as a modern OS), these two are grandmasters of computing and deserve the many accolades and awards they've won. Still, without their names attached to the Go programming language there'd have been little to no notice paid to it for reasons I'll outline below.

And, of course, the addition of Google's name to the list doesn't hurt. There is a large amount of Google fanboi-ism out there that's driving much of the buzz around this new language.

Yet...

This language doesn't deserve the buzz. At all. It is for the most part devoid of innovation and, in fact, in a few places, falls short of what a normal modern language provides. Had this language been released without the three names attached to it the world's response to it would have been a huge collective yawn, and this is only if one presumes any notice would have been given at all. Putting this another way, were this language designed as part of an undergrad course in language design it would have earned a solid B.

Innovation

Now, not to take away from the genuine innovations that Go has in it, I'll put them front and centre:

It's because of these three innovations that Go deserves a B in a language design course, in fact. (It could have even earned a B+ were it not for the really ugly syntax, q.v. below for details.)

Innovation? We don't need no more stinkin' Innovation!

So, that's the innovation. These are innovations. Two of them are very innovative. Too bad they're attached to a language that is otherwise a major step backward in language design.

Exceptions

The first step backwards is the lack of exceptions. This is such a major step backwards that I'm wondering if Thompson and Pike have entered senility! Exceptions (or some form of non-local transfer of control) are absolutely essential in any software project of any size. The reason has been known for decades: errors are usually, in any non-trivial software, detected where it is impossible to determine how to deal with it, while the levels of the software that know how to handle the error have no way to detect it. Something has to transmit that information from the place where the error is detected to the place where it can be handled. The old structured programming approach of returning explicit error codes fails on several grounds (not least of which is the problem of programmer laziness). The biggest two are:

Generics

Another regressive problem is the lack of generics in the data types. You'd think that the designers of Go would have looked at the problems with Java when making their language. One of the worst design decisions made in Java was making all collections work through a process of down- and up-casting variable types in collections through the underlying "Object" type. This made code type-unsafe (kind of defeating the purpose of all those tediously repetitive type declarations) and has led to problems for years even now that Java has generics. (The generics are not well-implemented and still have type safety issues related to casting in edge conditions.) Hell, you could look back farther than Java for this. C++ was originally this way too and the latter-day workaround to this -- templates -- while typesafe are extremely complicated, ugly and much-derided outside of the C++ community as a result. If you design your language from the ground up to support generics, however, you avoid many of these problems. The Go designers chose not to do this. I predict that generics will be added later on and will either have major semantic issues (like Java) or really ugly syntax (like C++). Or possibly both.

"New Jersey" Design at its Best!

The aggravating part of all this is that the reasons given for these decisions come straight from the New Jersey approach to design. According to the the language design FAQ, the reason for not including these two features boils down to "we found it very hard to implement so we're passing the difficulty of the problem on to each and every programmer who chooses to use our language".

Why not just make them program in assembler? The whole point of using a high level programming language is to have the language and its runtime handle the difficult, fiddly bits so that the programmer can focus on the problem domain instead of the minutiae of implementation. A language designer saying "I chose not to solve this difficult, but common, problem because it's too much work" is rather like a car designer saying "engines are hard to design, so we'll just make the passengers of the car push the vehicle". This attitude is especially aggravating when you're dealing with a topic which has been solved in prior art! Generics have been part of language design for decades now! Don't like Java's generics? Or C++'s? That's fine. They both suck. Look at other languages. Try Dylan. Or Eiffel. Or Modula-3. Or any of a hundred other languages that tackled this and won. Don't cop out and whine about how hard it is!

Syntax

Still, with even these kinds of flaws, Go would get a solid B+. So why am I marking it down to B (and maybe even B- if I'm in a bad mood)?

The syntax.

Aside from it being Yet Another Squiggly Brace Language (q.v. B, C, C++, Java, C#, yadda yadda yadda for details) -- a continuation of the C blight, in short -- there is special ugliness in Go's core that makes me loathe it on sight. I'll just show a single example taken from the language's home page: s := sum(&[...]int{1,2,3});

This was the first real "WTF?!" moment while I glanced over the language. I am no stranger to terse and cryptic languages. I'll pit Erlang and Haskell against most languages for terseness and occasional ugliness. (Erlang records, I'm looking at you here!) There is, however, in my view, a difference between being terse and being ugly. Terse means the information is densely packed, but once you know the language it's easy to pick out the pieces. Ugly means the information may or may not be densely packed, but even if you know the language it's difficult to pick out the pieces. I've read and re-read the explanation for the supplied code a dozen times. When I read the explanation I can understand the code. If I leave it for an hour and go back, however, I cannot figure it out and need to read the explanation again. This is just bad design in my opinion. Erlang's records verge on this level of ugly, to be fair, but Erlang has one or two pieces of such ugly syntax. Go has many of them. I just showed you one example. Here are a few more:

More Disappointment

Other disappointments (but expected ones given the background of the people involved) in Go are:

Well, I'm out of steam on this rant. Why the vituperative venom if Go is so uninspired and boring? It's the noise around it, really. It's yet another celebration of technical mediocrity that has caused computing to never really live up to its potential. This offends me at a profound level.

--Michael T. Richter, November, 2009