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.

It may well be that Go is not adequate for production services unless your shop is literally made up of Go experts (Tailscale) or you have infinite money to spend on engineering costs (Google).

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.

Yeah, anything that gets a rise out of the creators of Go is good in my book.

The guy still thinks computers have 64 KB of memory and we need to economize on the length of identifiers. Nothing he says or does should be taken seriously in this day.

He'd probably like an appreciation note if it was written with all vowels taken out.