Is Go Lang worth learning or not? I wanted to know. These were my steps for making (up) and answer. It was a rough but short road for me. I determined that I like it and that determination shocked me. It totally went against my intuition (which proves nothing). My wrong-ness surprised and delighted me. And inspired me to capture both my conclusion and the process. That is what follows.
Introduction
Analogies are a bridge, useful to get from one point to another but dangerous if you stay there too long. With my apologies for the length, because I didn’t make the time to write something shorter for fear that I would fall off the bridge resulting in a complete globbing of dribble here, I proceed.
Analogy
In custom software development you easily find three kinds of chefs who:
- Get paid to prepare fun new dishes, and after delivery move on, to the next new dish. For example, a new dessert made with durian, no precedent and the world loves it.
- Get paid to prepare it and then clean the kitchen during the first few weeks of the new item on the menu. For example, demand is high so mostly you prepare it and deal with the fact that in order to prepare this dish you use the most complicated tools available and you spend five hours cleaning the kitchen so people can spend five minutes enjoying the dessert.
- Get paid to both keep the item new and interesting, for the next five to ten years, while supporting the item as it ages and changes and faces new and unforeseen expectations. For example now in addition to durian use dragon fruit, in addition to a pudding make it a cake, and do it all without the original recipe or people or anything.
Each job pays well and has both negative and positive traits depending on how you feel that day (for example, did you eat your Wheaties or not). They really each can be fun depending on your attitude. But attitude is out of scope of this blog post. Research, observations and conclusions are in scope, though.
Research
My research flow and comments
- Talked to friend #1 and he said that it is good
- Talked to friend #2 and he said that it is awesome and provided references
- I worked through the first 1/3 of Go by Example. It was good for examples. It helped me understand that I wanted to know the designers philosophy behind the design of the language. So I kept researching. Researching is not a perfect word, but good enough.
- I read Why Go’s design is a disservice to intelligent programmers. It had 167 comments with the post (Hacker News had 160 and Reddit had 914). I read both the article and the comments and I am happy that I did. It revealed some strong feelings and small examples. There is some good discussion and links through the entire page that I won’t reference.
- Finally I ended up here and I wish that it is where I had begun
Conclusion
Short Version
If you read one article about Go lang, then read this one.
It covers everything that you ever wanted to know about the philosophy behind the system and the results of that philosophy.
Google and their problems solved by Go are mentioned so many times that it is a distraction from the virtues of Go. So when you read it, just replace “Google” with “Your Company Name” and the article not only will read well to your but also you will get excited about Go itself.
Long Version
Experience Matters
My conclusion, based entirely on my experience, is that Go Lang is designed for all three kinds of chefs (from the analogy above). That is exciting. Can I decorate “exciting”? No, but my illogical desire to do so is strong. I’m not going to torture you with more analogies. But I will torture you with further explanation.
When I finally started to “know what I was doing” I started to design and implement software systems that were built to run for years and years and to be well supported and even fun for the maintainers. This was learned painfully and without any mentoring (disappointingly). My decisions made for grumpy first-line developers because I lovingly barked what and why:
- Use one code format(ter)
- No battle about least important aspect of system
- Use one linter
- Catch easy stupid errors
- Minimize external libraries
- Exclude libraries likely to wither away
- Maximize personal investment in implementation and thoughtfulness for long term system viability and support
- Build/Test/Run before doing anything
- Fast dev cycle
- Tools, frameworks and ideas serve your system, not vice versa
- The downfall of most tools, frameworks, and ideas is that you often end up serving them to little or not benefit. Case in point: function composition in the form of the Go Interface is simple and powerful. It has all of the power of a framework with none of the baggage and burden. Go is simple but not simplistic. Expressive but not needlessly complex.
- No programming for personal entertainment (PFPE)
- All of the above
The two biggest trouble makers are always PFPE and external libraries.
Programmers get bored so they start PFPE. That always leads to messy, complex, and unmanageable code. Desire for Generics are usually a loud and disturbing indicator of PFPE. Complex object hierarchies beyond comprehension without 35 minutes of study are another red flag. These things make maintainers miserable, who eventually quit. I won’t lean to hard on this point, because we’ve all seen this (and done it, too, most likely). Just as bad are withering libraries.
I’ve inherited too many projects where the external libraries went from vibrant and vigorously supported to dull and abandoned. Yuck. Reference a library for one giant method and it breaks and nobody wants to replace it, because it is never simple to replace. Otherwise somebody would have written it themselves. That is one of the points about Go that is lost by us folks learning Go.
One Of Pike’s Points Says It All
Pike is quoted saying that it is better to copy and paste little pieces of code then to reference an external library. At first blush it sounds like a control-freak, “command and control”, “bondage and discipline”, worst-practice style programming language philosophy. No, no way. But this reference is revealing if you look at your own experience.
The external library for simple stuff syndrome (ELF3S) results in using code that nobody really understands or cares to understand because they didn’t write it, it isn’t part of their system, so they don’t really care to support it. So when things inevitably break, you end up using a library completely disparate (cognitively) from your system. Yuck. It has all the bad properties of software and none of the good ones. It is NIH syndrome when the code is sitting in your own lap. It doesn’t get any worse than this: nobody wants to touch and when they do they get mad about it. That usually makes things worse because when people hate maintaining code they usually leave their job. Now you’ve got two (or more) problems. Go faces this phenomen flat out and creates an environment where maybe none of this happens.
This is why Go is a polarizing language. With enough of a certain kind of experience, you look at all of Go’s decisions that Pike covers in this article and you jump for joy, cheering, that the system you implement will survive, survive well, and the maintainers will enjoy maintaining. For most of us, this is unheard of in every way. And it should be heard of. We ought to contribute to making it happen and Go is one way to do it.
For Go: Hear, hear! Long-lived development is finally here.
And that is why I’m going to keep learning it.
I wouldn’t disagree with anything here (actually I agree with all of it), but I would frame the “PFPE” point differently: your programming language should not distract you from your actual task.
This is something that I’ve experienced with Ruby on Rails, and I’m getting the same sense from Go, but have never felt with any other language of framework. If the language and APIs that you are writing code with are sufficiently well-designed and consistent, you stop needing to talk about them. Instead of every discussion revolving around architecture and the technical details of the implementation, you are focussed on the business problem, because there is nothing interesting to say about the technology.
Thank you Stuart for sharing that. What you shared makes sense and those feature are desirable