So You Don't Like Go?

I've noticed a few quite negative blogs about go lately. And a 5-year-old one even got recycled in r/golang this week. (I intentionally don't include links to them here, as I don't want to do any finger pointing. I'm sure you came across such blogs, too.) These blogs tend to zoom in on details of Go that weren't designed well in the authors’ opinions, often delivered in a negative tone.

Don't get me wrong: Some criticisms are certainly valid, and pointing out genuine shortcomings is how a language evolves and improves. However, many of these rants are only expressing the author's dislike for a particular design decision that other languages do differently (but not necessarily better). There is a difference between constructive criticism and language rants that superficially pick nits, just for the sake of complaining. Those don't really help anyone.

All languages have flaws

The truth is: all languages have flaws. There is no such thing as a perfect language. This is why there's always someone who invents a new language that is supposed to be better than the existing ones, avoiding their shortcomings. But in decades of inventing higher-level programming languages, the one perfect language that is clear and precise with no foot slings and pitfalls, still doesn't exist. And it probably never will.

The reason is that language design involves countless tradeoffs. Every decision optimizes for certain use cases while potentially making others more difficult. What feels intuitive to one programmer seems counterintuitive to another. What works beautifully in one domain creates friction in another.

Be pragmatic

This is my advice to everyone who is prone to getting mad at language flaws (and I'm not excluding myself): Pick a pragmatic approach. When you learn a new language, you'll inevitably stumble over some details that are difficult to grok, seem counterintuitive, overly complicated, or otherwise flawed. Maybe they are, maybe it's only your perception, shaped by years of internalizing the concepts of other languages. Your “muscle memory” wants to type code the old way, and anything different can feel wrong.

Instead of getting stuck, try this: If you find a (true or perceived) shortcoming, learn why it's there. Understand its background, history, and raison d'être. Then learn how to use it right (or avoid it if you must) and move on. Remember you'll get productive in a language by learning to use its good parts well, not by starting a personal crusade against its flaws.

People have built great things in lesser languages than Go. It's just a matter of the right mindset and decent skills (that anybody can acquire). Go does have a few rough edges, but it certainly does a whole lot of things right. Look at the bigger picture, rather than the small details. You'll always be able to find a fly in the ointment if you look hard enough. But then, what have you won? The ones that understand and use all the great features of a language will be miles ahead while your mind is still busy finding nits to pick.