Crossfire: High-performance lockless spsc/mpsc/mpmc channels for Rust

Using stuff like this, does it make sense to use Rust in a golang-style where instead of async and its function colouring, you spawn coroutines and synchronize over channels?

It doesn't matter if you use channels or mutexes to communicate between tasks, you still need your function to be async to spawn it as a coroutine. Your only choice is between coroutines (async tasks spawned on an executor) or regular OS threads. Channels work with both, the rule of thumb is to use async when your workload is IO-bound, and threads when it is compute-bound. Then, it's up to you whether you communicate by sharing memory or share memory by communicating.

It does matter. Using channels makes control flow much more difficult to understand, but allows you to avoid wrapping everything in its own mutex (or RefCell) and local reasoning is easier to understand. There is also a difference in latency and cpu utilization, both of which still matter in io bound workloads. I honestly don't think it's one or the other but optimal usage is a mix of both depending on specifics of the use case. Channels are great for things that you want to be decoupled from each other but it needs to hit a certain level of abstraction/complexity before it's worth it.

Even folks who write modern go try to avoid overusing channels. It's quite common to see go codebases with few or no channels.

> Your only choice is between coroutines (async tasks spawned on an executor) or regular OS threads.

Thats not true. There are stackgul coroutine libraries in Rust too. I believe there's one called "may". They are admittedly not that widely used, but they are available.

If you are more like "parallel" than "async" totally yes!

here "parallel" is used in the most broad sense where you have (probably unrelated) tasks that are mostly independent for each other and run to completion. In that case "async" is an anti-pattern. So if you work more process-based that switch-based go!

May has unresolvable soundness issues, which is part of why it’s not popular.

I meant, when it comes to choosing between threads or async/await, it doesn't matter if you use channels or something else. Both can be used with them. My original comment wasn't very clear it seems.

Of course it matters what synchronization primitives you choose, for the reasons you gave.