tl;dr: Go is a dumb language because it does not provide enough abstraction. (Or with the underlying tone: Go users are just to dumb to understand superior lang

tl;dr: Go is a dumb language because it does not provide enough abstraction. (Or with the underlying tone: Go users are just to dumb to understand superior languages.) I agree and disagree with all your points. I have written C++ and Prolog professionally for years, then some Java (because employer), with a little Haskell on the side (hobby projects). I am in a bind when it comes to PLs. I prefer the abstraction of C++ and Haskell (or Prolog for the domains where it fits). On the other hand, it is easier in powerful languages to get complete mismatches between the level of abstraction and the abstractions that are used. To take three widely-used C++ libraries as an example: - Boost: highly template and template meta-programming driven. - Qt: basically C++ as C with classes, with moc for signals. Really only templates for collections. - Xerces/XQilla: 90ies style C++ with global state, and too many Java SingletonFactoryProxies. In projects where you use different dependencies with different styles, things can get ugly. Also, your policy-based design may not be understandable to your 'C++ is C with classes' colleagues/contributors. In the end there will always be interaction between expressiveness and maintainability/accessibility. The right abstractions can improve both. Too much magic (page-long type signatures, too many levels of templated indirection, etc.) can make everyone's lives miserable. The graveyard of ugly C++ libraries shows that finding the right abstractions can be hard, even for experienced programmers.