A major issue when dealing with the tokio runtime is Send bounds requirements, I don’t think the single-threaded runtime changes anything because these are API-level issues. You can use spawn_local to avoid migrations but you can do that on the multithreaded runtime just as well.
And then a lot of tools and libraries which get layered over tokio (or assume a tokio environment) will require send futures anyway.
EDIT: Sorry to join in the multiple responses. Clarity for others: "current_thread" by itself does not relax Send, and many libraries aren't configurable to make everything use LocalSet.
Somewhat relatedly, a major (early) stumbling block for me with the multithreaded runtime was trying to keep references across await points. While boxing them is always an option, things also got much easier when I realized that while &T is only Send if T is sync, _&mut T is send if T is send_.
Is it?
> the Send bounds are only there in the multithreaded runtime (because it might need to Send a task across threads).
Tokio is interacted with using free functions which dynamically look up the current runtime, they could not have a different signature even if tokio had different runtime types, which it does not.
> The single threaded runtime will never do that, so its futures don't need to be Send.
Please do point to the ?Send spawn (not spawn_local) which supposedly exists for the current_thread runtime. You can't even spawn_local at the toplevel of the current_thread runtime.
Even in a single threaded runtime spawn requires Send and you need to use LocalSet + spawn_local for !Send futures.
current_thread doesn't even create an implicit LocalSet, if you try to `spawn_local` from the top-level of a current_thread runtime you get a panic, exactly like a multi_thread runtime.
And of course it's an accumulation of trait bounds on everything, which makes for a downgrade in readability.