Proverbially Speaking

Go is a pretty minimalist language. When you get down to it, there’s not much there. There are only 25 keywords. Types come in 3 flavors, simple types, aggregate types, and reference types, and the magic interface. Simple types are numbers (int/uint/float with precisions), strings and booleans. Aggregates include arrays and structs, while reference types are slices, pointers, funcs, and a go-ism, channels. That’s it.

Any yet, you can, and people have, written significant system/back-end/control-plane tools and systems with it. Things like Kubernetes, Prometheus, Docker, and Terraform for example. We have too. BatchAPI is Go.

Another thing about Go is that the community has more than a little bit opinionated. That’s why when you look at Go code, even poorly written Go code, it looks like Go code. The biggest reason for that, of course, is gofmt. While you can write Go with your own style, there is one true style, and gofmt will quickly and easily apply it for you.

The other way it does that is through what’s colloquially known as idiomatic go. The kind of Go that matches the way other Go developers think. And a lot of that comes from the Go Proverbs. A few sentence fragments from a talk by Rob Pike, one of Go’s developers. And they capture not how the language works, but how you should use it. Ideas designed to help developers write code in a way that used the language the way they thought it should be used. There’s even a nifty little website and set of icons/images.

Some are very Go specific, like Cgo is not Go or interface{} says nothing, but others have broader reach, like A little copying is better than a little dependency or Documentation is for users. Of all of them, the one that speaks most to me is Clear is better than clever.

Go is not about writing as few lines of code as possible. It’s not about packing as much logic into a single line as you can. It’s not about implicit handling of errors somewhere at the top of the chain. It’s very much about doing something and responding to what happened, even (especially?) if it wasn’t what you wanted to happen. Because it’s not about just writing the code. It’s about maintaining it. Supporting it. Extending it. Basically keeping the cognitive load as low as possible when interpreting the code itself so you can focus on the user’s problem and not have to worry about understanding what the code is doing behind the scenes.

What do you like about the proverbs, and what other ones should there be?