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.
The HTML5 specification explicitly asks you to not think about this yourself: "for security reasons, it is imperative that those rules be followed precisely. Differences in how invalid byte sequences are handled can result in, amongst other problems, script injection vulnerabilities ("XSS")".
They have HTML templating (which is pretty useful), but AFAIK html parsing is in an experimental module which may never be included in the stdlib because of the reasons you mention, it is over here:
code.google.com/p/go.net/html
But I don't see this mentioned in the rant.
Re the rant linked, it doesn't strike me as very useful or informative. Compile time is a huge issue on many projects, even ones which are relatively simple - I've worked on a few involving C++ and many of them had compile times in the minutes, which was pretty dispiriting and definitely got in the way - on much larger projects of course this is a bigger problem. That golang compiles far faster even on large projects is a definite plus. Bash isn't the only choice at all for systems programming or munging data as he implies, there are lots of other better tools.
Re his call for SIMPLE GUI PROGRAMMING I really can't agree at all - the best ecosystems let the tooling get out of the way, and some of the worst tools make a point of making you click around a confused trainwreck of a UI to perform simple tasks (Apple's Xcode or Eclipse come to mind). That's not progress.
The section on operating systems is similarly wrong-headed; talking about adding a huge number of abstractions (and APIs to go with them), which would lock programmers in to the ecosystem they choose even more completely and be a huge block to cross-platform work. That's a rather dystopian future - I'd rather leave the OS as a collection of badly debugged device drivers (to quote Andreessen), and let other systems build on top of it. There are some really good ideas in unix, and some nice ideas in golang, and the focus on simplicity is not only for the compiler writers, I think that's an incorrect assumption.
It's much easier to denigrate than to actually create, and if the author really cared about any of this, he'd take the time to do something about it, but has he attempted any of the points on his list himself since?
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.