That nothing about it’s good? It’s the same shared-memory concurrency everybody else has, that it had to built-in a thread-safe queue doesn’t fix that.
In some ways it makes it worse, because it’s easy for the unwary to assume channel = safe, whereas nothing could be further from the truth: a channel only protects itself, sending a slice through a channel is not safe, sending a map through a channel is not safe, sending a pointer to a channel is not safe, etc… and this is transitive, sending by value a struct which contains any of those isn’t safe either.
Not to mention the easy and common issue of implicit concurrent sharing via `go` closures.
Here’s a bunch of examples: https://www.uber.com/blog/data-race-patterns-in-go
And these are data races, not merely concurrency issues.
You have a very myopic view of what makes concurrency designs good.
I suggest you broaden your perspective, and consider the practical effects of language design on humans, as opposed to just mathematically provable safety.
Read the Structured Concurrency notes (https://vorpus.org/blog/notes-on-structured-concurrency-or-g...) for the reasons why.
That’s because people confuse “easy” and “good”.
Go has easy concurrency, but it’s not good. The opposite really. It’s at best the similar problematic model you get in other, older, procedural / oo langages. At worst it’s a lot worse given how difficult it is (and even more so was before generics) to build abstractions and concurrent data structures.