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.
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.