[eropple]

Languages don't need to make parallelism and concurrency easy if they're sufficiently expressive by themselves. Go bakes in things that a competent programmer doesn't need baked, while ignoring things that make a competent programmer better at their jobs (yes, it's the generics problem again!). Making channels primitives isn't a positive to me when it's something I can implement as well or better in userland--which I can, even in a language as middling and Java-1.1y as Go.

Go's channels are effectively a locking message queue (Java's had one of these since at least Java 5) plus a (usually global) thread pool. Not too long ago I implemented the moral equivalent in C++11, using only the standard library and in a unit-testable format, in forty-eight lines. Selecting across them is nice syntactic sugar, but is likewise able to be mimicked in plenty of other languages. Or, alternatively, I can use way more pleasant abstractions like Akka or Celluloid in not-Go languages (sending up Erlang when Akka provides a very similar experience in Scala or Kotlin--even Java, if you're using Java 8--is...curious).

I guess you can make an argument for TOOWTDI, but I don't find that to be persuasive when the OW in question is middling.