They don't scale well because of lock contention, the syntax is missing standard concepts like timeouts etc, & the behavior around edge cases around initialization, closed channels, nil values etc is bizarre.

Aren't they "lock-free" though?

Not in the least. They are a thin veneer on top of a giant mutex.

That's quite disturbing :P Any idea why they didn't implement channels as a lock-free list, ala java.util.concurrent.ConcurrentLinkedQueue?

I don't presume to speak for Go's developers, but I would guess because it's not that big a deal, especially in a cooperative environment. "If I can't obtain the mutex, yield" is a perfectly defensible thing, and is easier to write and probably to maintain than a lock-free list.

Having Java's concurrent stuff is nice, don't get me wrong, but I can understand it not being the biggest priority in the world to go rebuild that later. As I've mentioned elsewhere in this thread, there are much bigger beefs.