I doubt it. Go has good performance for most applications out of the box, but if you're hitting the limits of what `chan` can do, it's either about to get very ugly (which goes against everything that Go stands for) or you should be looking at something like Rust at least for the hot paths.

Not really if chan are problem perf wise then you use mutex, it doesn't have to be ugly.

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.

The one thing I would love to see a good story in chan/go concurrency in general for still is 1-to-n fanout. Right now a lock and a loop seems to be the answer, which is a bit of a blunt tool. Possible I'm missing an option, though!

1 producer to many consumers?

just spawn goroutines that select on the (optionally buffered) channel

if you need to fan out even further, repeat this on the spawned routines

Not quite. Produce one message, have arbitrary <n> consumers all read that exact message.

>about to get very ugly

That's all relative. There are legitimate reasons to trade a bit of complexity for a bit of speed. Go is not special in this regard.

There are some similar lock free data structures in golang up on github such as "onering".

One challenge of writing this kind of code in go is that go routines are not pre-emptive, so you can't just port over an implementation that works in c.