I think it is time to face the fact CSP style channels are a bad idea if you don’t also have the occam semantics for channel scope. (I know there are other people here that understood that sentence).

The problem in golang is the channel cleanup, particularly. is a mess. In occam they come and go simply by existing as variables in seq or par blocks. Occam is very static though, so the equivalent to goroutines are all allocated at build. (Occam pi attempted to resolve this iirc).

https://en.m.wikipedia.org/wiki/Occam_(programming_language)

Some of the patterns in this library are reminiscent of constructs occam has as basic constructs, such as the for each block, although the occam one must have the number of blocks known at build time.

The fact so many people in golang reach for mutexes constantly is a sign things are not all well there.

+1 for understanding the sentence.

Channels are just another synchronization primitive in your toolbox. They do make some things much simpler, but there's no reason to reach for one if a mutex does the job.

The usage of mutexes doesn't make channels "bad" for the same reason that usage of atomics doesn't make mutexes bad.