Languages don&#x27;t need to make parallelism and concurrency easy if they&#x27;re sufficiently expressive by themselves. Go bakes in things that a competent programmer doesn&#x27;t need baked, while ignoring things that make a competent programmer better at their jobs (yes, it&#x27;s the generics problem again!). Making channels primitives isn&#x27;t a positive to me when it&#x27;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.<p>Go&#x27;s channels are effectively a locking message queue (Java&#x27;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&#x27;re using Java 8--is...curious).<p>I guess you can make an argument for TOOWTDI, but I don&#x27;t find that to be persuasive when the OW in question is middling.