But in either case the boundary between the two types of async work is never easy to cross.
I have a graphics program that has about eight different threads doing different things. The draw thread is high priority and does only the things that have to be done on the draw thread. The update thread, medium priority, is doing change events that affect the scene. The movement thread is doing repeated per-frame movement, computed in parallel with drawing. The asset-loading threads, low priority, are making blocking HTTPS requests to get assets from remote servers, and decompressing them, the biggest compute load. Plus there are a few other threads that do various intermittent tasks.
This works well in Rust because the language catches locking errors that cause race conditions. Doing this in C++ would be tough.
You don't really need async until you have thousands of things waiting.
> How do you properly mix IO/compute (in any language)?
Good question, it’s a really hard problem.
In principle you are meant to use threads, the OS will automatically switch to other work while you are waiting for IO, like with async. But there are difficulties with threads too: memory overhead, switching overhead, thread limits… Although I am getting the feeling that they have a much worse reputation than they deserve. More projects should try switching to threads and actually measuring the difference.
It works for simple situations. It certainly preserves backpressure, although a slow CPU task can impact other users of the same thread pool.
[1] https://trio.readthedocs.io/en/stable/reference-core.html#tr...