preface

Simplicity is the ultimate sophistication. —Leonardo da Vinci

I thought Go was easy, but the story was different. Go was simple. Back in 2012, I needed to design a distributed network program. This program had to pull and interpret various kinds of data from thousands of external sources and send the results to other services in real time. It needed to run fast because I was working with constantly updating data sources, and other services depended on timely and accurate results.

I had heard good things about Go, such as its ease of use, strong type safety, and great support for concurrency, so my team and I started writing our program in Go. My team consisted of veteran programmers, but this was our first experience with Go. We came up with a prototype within a month. Initially, everyone in the company was satisfied with the efficiency of the program, but after a short while, things started to fall apart.

We were coding in Go as though it was an object-oriented language we already knew. Instead of finishing the task at hand, we spent a lot of time trying to design our program with unending abstractions. Circular dependency issues were everywhere, and our code became challenging to read and work with. In the end, we had to rewrite most of it.