I’ve dumped 18 years of C++ experience for Go in 2018, and never wanted to come back. Took me a couple of months to become accustomed.
The main Go’s feature is a green light for ignoring OOP baggage collected for decades, which makes writing code unnecessary burden. And Go have tools for not doing that.
Yes, sometimes it can be a bit ugly, but if you’re ready to trade academic impeccability for ease of use, it’s a real blast.
I’ve seen a lot of bad code in Go, which tried to do OOP things taught in school or books. Just don’t. Go requires a different approach, different mindset. Then everything falls in their places.









Well written article. Also points are valid. What I disagree with is that author overestimates dangers that those ugly aspects pose. There are linters and unit tests to catch those things before they reach production. I can’t quickly recall when the last time failure to initialize a structure field was a source of bug that was pushed to master (in fact, I love to use zero values as intended). Most bugs I remember are the logical ones, which no compiller can prevent. But then, I am senior developer, so maybe I can’t understand the struggles of juniors.
Reality says otherwise. I worked for a few large companies that chose Go as their main code base language. I can also see wide adoption of Go as backend language. It not only did not increase development or maintenance costs of those products, but reduced them. From the perspective of developer, who used C++ before Go.