Context Is Everything

One of the things I used to tell my Go course students is that the context of what they are doing is key to evaluating whether a piece of advice applies to it.

Take Go and its community. The language originated at Google as a solution for building software at scale. Championed by Docker and Kubernetes, it is now among the first choices for building cloud infrastructure or services meant to process millions of requests per hour. Naturally, these are among the areas where one finds most Go jobs.

Developing such applications requires a certain level of discipline and an attitude towards writing code more optimized for the machine than for the humans who will maintain it. Inadvertently, it leads people new to Go to accept that this is the only way they should write Go code. Often artificially limiting their options of developing the best solution for the problem at hand.

Most problems aren’t of Google’s scale. #

Go is a fantastic general-purpose programming language. But most problems out there aren’t of Google’s scale. Neither are most teams. I am usually skeptical when some “best practice” coming out of a 1000+ person enterprise makes it into the general public and becomes the new way to write idiomatic Go code.

Idiomatic is what works for you and your team. #

My comrades and I don’t write idiomatic Go code by most accepted standards. We don’t prematurely split our code into micro-components, and neither do we glue them with the latest and greatest RPC protocols. We prefer building (well, distributed) monoliths (hello, Buffalo!). We use reflection, pass functions around to make code more fluent, and avoid scattering interfaces everywhere; heck, we even have some global state where we see it fit.  

And yet, we keep building awesome things. Things that are still going to scale better than most other competing applications on the market. Thanks to Go’s transparency and relatively little abstraction, we are aware of things we can squeeze some more performance out of if the need arises. We can continuously optimize for the remaining 20%. But the important part is - we have found a balance that works for us as a team.

And that’s my advice to you too. It is good to keep yourself up-to-date on established development practices, but idiomatic is what works for you and your team at the end of the day.