Mutexes cause performance problems.

What I'm saying is if channel are too slow you can re implement something with mutex that will be faster and it doesn't have to be ugly.

https://youtu.be/DJ4d_PZ6Gns?t=535 ( it's one of the best Go performance video on Youtube )

There are applications for which even that is not enough. When you get to that point, it's best to not use Go. In fact it's best to have known that you would get to that point and not use Go in the first place.

One example is high-performance routing on 10Gbps networks using user-space networking. Pretty much every cycle counts into your throughput numbers, because the rest of the hardware can barely keep up with the network card even before you're trying to do something. Go is a poor fit for this use case.

(This from someone who has been accused of being a Go shill. I use it a lot and like it a lot professionally, but it is no more suitable for every task than any other language.)

It's true but you're talking about a very specific case, a case that can only runs on C / C++ / Rust, for 99% of scenarios it won't be an issue.

There are large scale online services ( in the millions req/sec ) that runs on Go without problems.

The point is: channels are slower than mutices.