> What is bad about it?

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.

> That nothing about it’s good

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.

Ah, you’re a fanboy. You could have just put that upfront I would not have wasted my time taking you seriously.

You wrote "That nothing about it’s good". That's stupid. I agree we are wasting our time.

Well, Ok, so the main thing that's good about it is that it's dead easy to start a goroutine. But that's actually bad, just like randomly jumping to any piece of code whatsoever is bad in in a procedural language.

Read the Structured Concurrency notes (https://vorpus.org/blog/notes-on-structured-concurrency-or-g...) for the reasons why.

I don’t know. I think the culture around go encourages effective/safe strategies for using go routines + channels. I think when channels are used as intended they can be quite effective. They’re not technically more safe than anything else, but I think the fact that they make concurrency more manageable is good.