It's a bad fit if you have enough compute work to keep all the CPUs busy. Then you're dealing with thread priorities, infinite overtaking and starvation, fairness, and related issues.
I have an unusual application, a metaverse client for big 3D worlds. It has to deal with a flood of data while maintaining a 60 FPS frame rate. It's essential that the rendering thread(s) not be delayed, even though other background threads are compute bound dealing with a flood of incoming 3D assets. This does not fit well with the async model.
This sort of thing comes up in games, real time control, and robotics, but is not something often seen in web-related software.
I think you're not familiar with web-related software.
> It's essential that the rendering thread(s) not be delayed, even though other background threads are compute bound dealing with a flood of incoming 3D assets.
This is exactly how the browser behaves, and why Javascript needs to be entirely async on the main thread.
For your application it should be very easy to spin up a render thread (pinned to a single core or whatever priority mechanisms you want to use) that loops, and use message passing to get the results from Tokio based futures.
If you create a library that uses async, you're forcing everybody that uses the library into async as well (with the same executor).
If somebody writes a library now that's generally useful but uses async, it forces others to use async or rewrite the library themselves.
On the one hand a lot of people put this down as whining about free code, which is somewhat true, but the infectious nature makes the whole ecosystem less useful if you want to build something non-async.
If you request here or via the email at my web site (in profile), I can provide a more detailed example from a test I have.
(note to self: see fn test_basic_sql_connectivity_with_async_and_tokio() .)
