Throughout my career I’ve written programs in C, Ruby, Python, JavaScript, Java, Elixir, Erlang, Bash, and more. Each of these languages had a lot of great things going for it but always at least a few things that bugged me a lot. C didn’t have modules, Ruby wasn’t fast enough, JavaScript and its type system made you question your sanity, and so on. This meant that each language had a specific use case, like all the different knives a chef uses. For example, a chef uses a cleaver to cut through big bones. Similarly, I’d use Java when writing big, objective-oriented programs and wanted to make a cup of tea between the time I started the program and it was ready to run. A chef uses a paring knife when making small, delicate cuts, and I’d use Bash when writing small, portable scripts. But I always wished I could find a language that was useful in almost all situations and didn’t irritate me.
Finally, I came upon Go, a language that can:
Go had more things going for it. So there had to be something that bugged me, right? But no, it was as if the designers of Go had taken all the stuff that bothered me about other languages and stripped them out, leaving the lean, mean programming language that is Go. Go gave me the same feeling that made me first fall in love with programming: that if something was wrong it was my fault, me getting in my way instead of the language burying me under the weight of all its features. If Java is the cleaver and Bash the paring knife, then Go is the katana. Samurai felt that katanas were extensions of themselves, things they could spend a lifetime with while pursuing mastery of their craft. That’s the way I feel about Go.
If you were to pick the software field where Go has had the biggest impact, it would have to be distributed systems. The developers of projects like Docker, Kubernetes, Etcd, and Prometheus all decided to use Go for good reason. Google developed Go and its standard library as an answer to software problems at Google: multicore processors, networked systems, massive computation clusters—in other words, distributed systems, and at large scale in terms of lines of code, programmers, and machines. Because you’re a Go programmer, you likely use systems like these and want to know how they work, how to debug them, and how to contribute to them, or you want to build similar projects of your own. That’s the case for me: the companies I’ve worked for used Docker and Kubernetes, and I’ve built my own projects like Jocko, an implementation of Kafka (the distributed commit log) in Go.
So how do you start down the path of knowing how to do all that in Go? Building a distributed service isn’t the easiest or smallest project in the world. If you try to build all the pieces at once, all you’ll end up with is a big, stinking mess of a code base and a fried brain. You build the project piece by piece. A good place to start is a commit log JSON over HTTP service. Even if you’ve never written an HTTP server in Go before, I’ll teach you how to make an accessible application programming interface (API) that clients can call over the network. You’ll learn about commit log APIs and, because we’re working on one project throughout this book, you’ll be set up to write the code we’ll work on in the following chapters.