4 ms·
1. Library creators do not want to have to deal with the headache over managing multiple runtime libraries and also between sync/async. IMO this is going to mak
by likeabbas 4y ago
1. Library creators do not want to have to deal with the headache over managing multiple runtime libraries and also between sync/async. IMO this is going to make Rust's library offerings very fractured, to the point where we will either be stuck on a legacy runtime for a long time or the hype for Rust will sizzle out because it's too difficult to write good code
2. Tokio has the best support right now but Tokio is very difficult to write libraries for and may not be the best designed async library. Monoio looks like a very good design and may be the best option for web servers because you don't have to deal with Send and Sync.
3. This method usually works but for async they should have been more opinionated. Stackfull coroutines line [May](https://github.com/Xudong-Huang/may https://github.com/Xudong-Huang/may) would have worked best for 99% of the use cases and maybe there could be a separate no-cost async setup for embedded. But trying to have both under the same async paradigm is causing huge issues.