Go Improves More Than Just Your Software
About a year ago my team and I decided to use Go to develop a DevOps web tool and its attendant micro services. The first thing we noticed is that there is a steep learning curve to get you into code that actually does something useful. Once you’re over that hump, bending the code to your will becomes a magical art-form we had not experienced since the days of C++. Rather than looking at the massive bureaucracies of Java code or the misshapen blobs of Python, we were looking upon the well structured spires and towers of well conceived and carefully crafted Golang.
Why is it a pleasure to work with?
Because it is such an opinionated language that by the time you get your code to compile, the distance to “actually working” is very short. The best way I can think to describe Go is to imagine that the development world were to reinvent C++ today with everything we’ve learned over the last 40 years, leaving out most of the mistakes of the past and adding in some pretty nifty borrowed concepts from more modern languages (garbage collection, composition over inheritance). Now I know that some people out there are going to say: “But what about generics?!? What if I accidentally set the wrong thing to nil???”
And to those people I say: Programming should be HARD!
It should be hard enough that it prevents your average business analyst from thinking that they can take up the mantle and do it just as well as their developers… remember what happened when we made programming easy in the form of Visual Basic? A gazillion man hours were spent wading through slogs of horror that were originally produced by people who should never have had their hands near a keyboard, but were then handed to actual developers with the statement: “Can you please make this work and finish it?” No. Golang is hard, and if you misuse it, it will cut you, but if you know what you’re doing and you take the time to structure your code and you teach yourself how to write clean well conceived code – Go will work… well… every time. It will allow you to articulate layers of logic one atop the other with confidence that the layers you wrote below will continue to work as expected. When you want to change something, it will mostly demand that you clean up after yourself. It will make you do things in the “one true way” that will require you to work through the problem until you can get it to fit in a Go shaped box. Once you’ve done that, you will have well structured, easily maintained and reliable code that you can be proud of.
On top of all of that, it also incorporates multithreading as a core concept of the language so that working on services (like a web server or a queue processor) that require threading is a breeze. The code is fully compiled into executables and libraries are directly downloaded from GitHub in code form. This makes it easy to trace into a library when there’s a bug and to fork a library with a quick fix if needed. There is also a well developed ecosystem of high quality libraries for Go. Unlike Java, there seems to be one or maybe two good libraries for doing a thing rather than a large selection of options of varying quality. I suspect this is in part due to Go’s libraries being built with the lessons of the past already baked into them. Those libraries also tend to be good because the people who wrote them had to go through the mind sharpening exercise that is developing in Go.
I guess what I’m saying here is that writing your applications in Go is as much about becoming a better team of developers as it is about developing code. One can write both good and bad software in any language, but there are few languages that force a developer to become a better version of themselves.
So… if you have a team and an opportunity to develop a green field project, I would recommend giving Go a try. It has a steep, but short learning curve. Once that curve is overcome, your team and project will become better for having made the change.