3 ms·
Maybe it’s just the hyper and related crates universe, but my perception (see my sibling comment) is that more and more of the ecosystem will be “async only”.
by boulos 6y ago
Maybe it’s just the hyper and related crates universe, but my perception (see my sibling comment) is that more and more of the ecosystem will be “async only”.
Like you, I think that’s sort of fine, because you can always roll your own. But it’s also kind of sad: one of the best things about the Rust ecosystem is that you can so effortlessly use a small crate in a way you really can’t in C++ (historically, maybe modules will finally improve this).
- lalaithion 6y agoI mean, you can always just use an async crate and use async_std::task::block_on.
- boulos 6y agoOnly if no other crate in your executable uses tokio or another executor, right? Mixing executors is approximately fatal, AFAICT.
- cjg 6y agoI think that's too strong. You could have two executors with no problem. What might cause issues is if code running on one executor needed close interaction with the other - such as running a task on the other executor. Most of the time this is just avoided by using only one executor. But that's not the only way.
- boulos 6y agoThat's a good clarification. What matters is if tasks "running on" one executor end up spawning / blocking on a task "on another executor". You can definitely have "side by side, who cares". The danger though is that you're just using some library, and if it suddenly assumes it can do tokio::task::block_in_place but you were using some other executor you get "Hey! No runtime!".