I almost flagged this, as I feel that the author is disingenuous; I don't feel he wants to engage in a productive discussion of these issues, makes no concessions to the technologies he brings up, confuses his domain with all domains, and falls back on superficial criticisms.

I did not flag it because his frustrations can still be the starting point to useful discussion. Something I would like to point out is that Go was designed with programmer productivity in mind. The author writes this off as "designing for the compiler," and the Go team did purposefully design Go to be quick to compiler. But that was not an end in itself. They designed Go to be quick to compile to make build times faster, so that programmers would spend less time waiting for builds. Rob Pike gave a keynote talk at SPLASH 2012 where he explained all of this in-depth: http://talks.golang.org/2012/splash.article I think it's worth noting that the talk is even entitled, "Language Design in the Service of Software Engineering."

So, back to one of my criticisms of the post: the Go team clearly tried to design Go with the programmer in mind. In particular, they were designing for a programmer who works on a code-base of millions of lines who works with dozens (or hundreds) of other developers. If the author wants to claim that the Go team failed at this goal, then that's fair. But I don't think it's fair to claim that this is not their goal.

The rest of the rant feels the same to me. The dig about category theory is clearly aimed at Haskell. I am not fluent in Haskell, but I have been convinced by those that are that being fluent in category theory is not necessary to be fluent in Haskell. Saying so is a boring way to dismiss a language.

Overall, the rant reminds me of an exchange I had with a fellow grad student many years ago. This was back when it was just starting to become clear that single-threaded processor performance was going to hit a wall, and we were going to have to go multicore. When trying to explain this, I was hit with, "I don't care, it's their job, they just need to make it faster!"

The authors goals may be good ones, but he refuses to acknowledge the hard problems people are encountering when trying to build the infrastructure necessary to even start to address those goals. Not granting people their incremental successes just because they did not solve the whole problem is, I feel, disingenuous.

Yes, the article is very much of a rant, which is necessary every now and again to prove a point.

I also feel that many of the points the author had aren't strictly related to the language, but rather its standard library. Which could be argued that you can't benefit from one without the other, but still. Most of his concerns seem to be easily fixable through a more versatile stdlib, but there are certainly cases to be made against that.

For example, I'm not sure I want a language's standard library to know about JSON and HTML parsing, features that seem to be a better fit for non-standard frameworks and libraries.

I surely prefer a language that comes with HTML/JSON parsing in the standard library, as opposed as trying to find which library is better implemented, hoping it will keep being maintained.

I can see wanting JSON parsing built-in, but HTML is another problem. There isn't an obvious way to parse broken HTML, and every HTML parser does it differently. When you need to parse some HTML, you need to think about the differences, instead of just choosing the standard library one.

At least with HTML 5 we have both a spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/) and a library to parse it (https://github.com/google/gumbo-parser)