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 hadn't really looked at Go before, but I have to say the generics issue reminds me of Java 10 years ago before it got generics. Java also had the goal of being simple, which is probably why it's so popular, but for me it was always too simple in the sense used in TFA (haven't tried Java8 yet though.) At least it looks like Go has higher order functions, but I don't see how they will be that useful without generics unless you subvert the type system.

I definitely think the too-simple nature of Java is the reason behind all the reams of boilerplate Java code found in most any Java project, and I can't see how Go would be any different. It seems like a shame not to have learned that lesson.

>>pivo+k4
I think the too-simpleness of Java 1 also has made Java 8 more complex than it could be. Java got generics 'the easy way' through reification, and that gave us the mess that is mentioned in http://java.dzone.com/articles/whats-wrong-java-8-part-ii:

"the methods of these interfaces have different names. Object functions have a method named apply, where methods returning numeric primitives have method name applyAsInt, applyAsLong, or applyAsDouble. Functions returning boolean have a method called test, and suppliers have methods called get, or getAsInt, getAsLong, getAsDouble, or getAsBoolean."

The solution that go offers for such problems seems to be to deny that there is such a thing as libraries and to promise to deliver migration scripts whenever changes in the language or its libraries break existing programs.

That approach works fine now, but I am not sure it scales to a situation where go is truly successful; in particular, I think go, at some time, will have to allow for dynamic linking to support commercial libraries, if it wants to become truly successful.

On the other hand, the times of copy protection on software being normal are far behind us, and CLR has an ecosystem for commercial libraries, that decompile so well that CLR libraries do not differ much source code. Maybe, I am underestimating the willingness of commercial vendors to start shipping libraries in source form.