zlacker

>>apta+(OP)
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).

>>carboc+I2
I thought the "sum" example was pretty damning. Bug count scales with code length so writing tons of boilerplate code to work around language limitations means you're introducing bugs.

>>Alexan+04
I believe that the purpose of `go generate` is to lessen the risk of this type of thing by handling the repetitive code generation for you, but I do agree that it's a limitation. If done by `go generate`, it's an additional procedure that you have to learn; if done by hand, it's a bug risk.

>>carboc+d4
Code generation is a giant spiked mallet for a nail which can easily be screwed with a small screwdriver. It has its uses, especially for generating schemas (like what Protobuf and Capnproto do), but for generating actual function implementations it's kind of absurd. `go generate` is a nice tool but it's not even remotely a solution to the no-generics problem.

Of course, the problem is that for the compiler implementation, those traits are completely reversed (adding generics at this point is like hitting the compiler with a mallet); and that happens to be Go's primary excuse for lack of generics/templating/macros/anything sane. I think dev ease-of-use matters a lot more than core dev ease-of-use though. Even if the compiler must grow in complexity and average compile time, the benefits to devs are worth it.