There are some fundamental assumptions in the Rust async system:
- The program is mostly I/O bound.
- All tasks have equal priority.
If your program isn't like that, the Tokio model is a bad match to the problem.
Real time control is not like that. MMO and metaverse game programs are not like that. Most web stuff is, but that's a special case. A big special case, but a special case.
Real time control can be like that as long as the computing parts are clearly bound within your performance requirement.
There's a few runtimes for IO bound work loads; monoio from bytedance comes to mind.
To be fair, the Rust async model itself was intentionally designed not to be prescriptive in the way you describe. You can build, and there exists, different task executors that can handle things like priority and many other execution models.
Async is just a way to describe a tree of concurrent tasks that may depend on (wait on) each other at certain points. It is mostly declarative.
Tokio has taken over as the default choice, but there's a reason why it's not part of the standard library, it is not meant to be the only choice.