Go is boring … and that’s fantastic!

I've been working as a professional software engineer for nearly 23 years, and I’ve been writing programs for about 38.

In that time, I've used a lot of languages. I love programming languages and learning about their new features and what changes they've made compared to the languages that came before them.

If you look at the past 10 years in programming languages, you’ll see lots of changes. C++, Java, Python, and JavaScript have gained new features, and new languages like Rust and Swift have changed rapidly since their introduction. This is all pretty exciting but it also feels like sometimes you can never catch up with all the ideas in all these languages.

And then there's Go.

The best way to think about Go is to think about all the things that it doesn't have.

• Go doesn’t have a virtual machine or an LLVM-based compiler.
• Go doesn’t have exceptions.
• Go doesn’t have user-defined implementation inheritance.
• Go doesn’t have overloading for functions, methods, or operators.
• Go doesn’t have immutables.
• Go doesn’t have enumerations.
• Go doesn’t have generics.
• And Go hasn’t added any major features since Go 1 was released in 2012.

The one exciting thing that Go has is built-in concurrency support via goroutines, channels, and select. However, it is based on ideas from CSP, communicating sequential processes , which was first described in 1978.

This doesn’t sound like a programming language from the 21st century, does it?

And yet, Go is the 3rd most wanted and (maybe not coincidentally) the 3rd highest paying language, according to Stack Overflow. Every startup in Silicon Valley is using Go to build their infrastructure. Docker, Kubernetes, etcd, Terraform, Vault, Consul, Traefik and lots of other cutting-edge projects are written in Go. So what's going on? Why is everyone interested in this boring language?

There are a few things that we have learned in the last 60 years about writing programs where there is pretty much universal agreement:

• We agree that it's better to find problems earlier rather than later.
• We agree that people are awful at managing memory in programs.
• We agree that code reviews help find bugs.
• We agree that on any project that requires more than one person, communication costs dominate.

When you look at single core performance, t he fastest 2019 Core i9 is less than twice as fast as the fastest 2011 Core i7 . Instead of getting faster, we're adding more cores to CPUs.  When you look at multi-core performance, it's a little better, slightly more than 2x faster.

It’s not just CPU performance that is limiting us. Forrest Smith wrote a fantastic blog post on the impact of RAM and RAM access patterns on performance. The highlights are:

• RAM is much slower than CPUs, and the gap is not getting better, even though CPUs aren't getting much faster.
• RAM might be random access, but if you actually use it that way, it's slow. You can read around 40 gigabytes per second from RAM on a modern Intel CPU if the data is sequential. If you do a random read, it’s a little less than half a gigabyte per second.
• Code with lots of pointers is especially slow. Quoting Forrest: “Sequentially summing values behind a pointer runs at less than 1 GB/s. Random access, which misses the cache twice, runs at just 0.1 GB/s. Pointer chasing is 10 to 20 times slower. Friends don't let friends use linked lists.” Ouch.

Finding Problems Earlier Rather Than Later

The Go language might lack features, but it ships with a great set of tools. Go's compiler is fast, and that fast compilation speed is considered a feature by the Go team. It lets you quickly see if your code compiles, and if it doesn't, it lets you see where the problems are. Testing is built into the standard library to encourage developers to test their code and find problems. Benchmarking and profiling and race checking are included out of the box, too. Very few languages ship with these tools and they make it easier to find problems quickly.

Memory Management

As we all know, Go has a garbage collector. You don't have to worry about keeping track of memory and that's a fantastic thing. Among compiled languages, garbage collection is rare. Rust's borrow checker is a fascinating way to get high performance and memory management, but it effectively turns the developer into the garbage collector, and that can be hard to use correctly. Swift's ARC can still leak memory if you make mistakes and forget to declare some references as weak. Now, Go's GC isn't as performant as these semi-automatic systems, and there are some situations where you need the extra speed, but in most cases it's certainly sufficient.

Code Reviews

Code reviews are important if they are done well. In order to have an effective code review you need to make sure that the reviewers are focused on the right things. Low-quality code reviews spend time on things like formatting. Go helps here because there are no formatting arguments when reviewing Go code, because all Go code is formatted the way that go fmt says code should be formatted.

And code reviews are a two-way street. If you want a review that works well, you need to make sure that other people can understand your code. Go programs are supposed to be simple, using a few well-understood constructs that haven't changed since the language was released. Because there are no exceptions, aspect-oriented programming, inheritance and method overriding, or overloading, it's very clear what code is calling what and where the values are returned. If you stay away from modifying package-level variables in Go it's very easy to see exactly how data is being modified. Since Go has changed so little, you can avoid the lava flow anti-pattern , where you can tell exactly how old some code is based on when a feature it uses was introduced into the language.

Communication Costs

How does Go help with this? We've already talked about how Go's simplicity, stability, and standard formatting makes it easier to communicate what your code is doing. And while that's part of it, there's something else as well. Go's implicit interfaces help teams write decoupled code. They are defined by the calling code to describe exactly what functionality is needed, which clarifies what your code is doing.