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.
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.
> 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.
May has unresolvable soundness issues, which is part of why it’s not popular.
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.