“Go’s design is a disservice to intelligent programmers”

My summary of the author's points: no generics, inexpressive, no good package manager, procedural.

Of these, caring about the fact that it is procedural seems pure opinion. Lacking a package manager is not really a language issue (PHP's package manager, for example, is not coupled to the core language).

So, we are left with the lack of generics and the lack of expressivity. I'm not deep enough in the weeds to be able to argue pro/con for generics intelligently right now, so I will concede that as a concern that has been raised by many.

The lack of expressivity seems to be an inexorable consequence of the goal of simplicity, so I'm sympathetic. That said, it seems to be a tradeoff acknowledged by Go's authors, not an oversight.

Overall, these points don't convince me of the author's thesis (or, at least, they don't seem to justify the title's degree of inflammation).

I hadn't really looked at Go before, but I have to say the generics issue reminds me of Java 10 years ago before it got generics. Java also had the goal of being simple, which is probably why it's so popular, but for me it was always too simple in the sense used in TFA (haven't tried Java8 yet though.) At least it looks like Go has higher order functions, but I don't see how they will be that useful without generics unless you subvert the type system.

I definitely think the too-simple nature of Java is the reason behind all the reams of boilerplate Java code found in most any Java project, and I can't see how Go would be any different. It seems like a shame not to have learned that lesson.

If you want a more complex Java you can have Scala. Scala remains hostile to newcomers with an almost vertical learning curve. I don't think anyone can seriously argue that commercial programmers need a more complex language.