A Grumpy Guy Complains About Complaining

Over the past couple of weeks I’ve seen a handful of “Why Golang Sucks” articles. A couple were reasoned, the rest were copy-cat, none of them make any sense to me.

It would be easy to get the impression from pop-software news that the last line of C was written about 5 or 6 years back, and the last small band of C++ programmers are holed up in a cave someplace metaprogramming. I can assure you, this is not the case. If nothing else, one need only consult the sources for the various language-of-the-month compilers, or maybe the source debs for the last 100 or so updates applied to your Ubuntu machine.

I get that C and C++ also “suck” in many ways, I have certainly spent a significant portion of my life scratching my head staring at gdb and emacs. I think of these languages, these tools, as something akin to violins and cellos. They’ve been around, virtually unchanged, for several hundreds years. They are an absolutely gigantic pain in the ass to play- they haven’t got any frets, they have tiny fingerboards designed to be played by scrawny, malnourished 15th century musicians. They’ve got tuning pegs designed for strings made out of animal guts and which rely on friction alone to stay in tune. They’re freaking baroque. And yet, they get played a lot. You might argue that their design actually encourages mistakes.

So here we find ourselves in a world with various better choices than C and C++, yet they still get used for a pretty significant chunk of all the coding that goes on in the world. Why is this?

I believe you can sum up the reason that programmers still use these languages as something along the lines of “because they knew what they were getting into”. The language, including the flaws, are known, and the developers go with it anyway. Maybe there’s some platform/library lock-in of course, some inertia. But we kind of know, disregarding the annoyances and frustrations of using C and C++, there isn’t much you can’t write in those languages, and the shortcomings are widely known.

Which brings me back to these Go articles. The entire nature of the Go language is documented. Exhaustively. It is perhaps the most true specimen of a post-internet computer programming language. It was birthed on the web in the wide open, the specs, the docs, the compiler and the library are all there for you to investigate. How is it then, that this number (well at least these 4 or 5 I’ve complaining about), managed to understand their own needs so poorly that they devoted a big chunk of time to learning and hacking on Golang, only to find that the language was missing some crucial feature that they can’t do without?

I’ll give you a hint, which is that there’s nothing wrong with the language. The problem is that we do a piss-poor job of understanding what it is we expect from programming languages right now, at least members of the pop-software culture (myself included). There’s a kind of tacit understanding, with regard to quality in a programming language that “I’ll know it when I see it”. In other words, I’ll learn enough to start writing a handful of programs in some new language, and then if the language is any good, it’s quality will gradually reveal itself to me as beautiful arrangements of code in my emacs buffer.

This is utter horse shit. This is like finding a new alloy of steel and then building a bridge out of it to see if its any good. If Go doesn’t have generics, and you know you need generics, why the fuck did you bother with Go? These details are widely, exhaustively documented; they are not surprises.

I’m not a golang enthusiast, but I am a lover of programming languages, and as a long time (but not brilliant) C and C++ programmer, I see a lot to love in Go. However, I’m thinking of Go in terms of its ability to replace programs and methodologies that I’d probably otherwise solve with the classic GNU autoconf/make/gcc conglomerate (avert your eyes!). It is important for people to understand not the language itself, but also where the language is coming from. When Rob Pike mentions that one of the initial motivations for Go was that it was taking too long to compile giant C programs, that should give you some intuition into the problems they were trying to solve with the language.

Go introduces some new kinds of problems, but nobody in the project is keeping them a secret. It’s the programmers responsibility to know what is required of the materials.