News for hackers. Stuff that matters.
Re:Why asynchronous Rust doesn't work by boulos on Tuesday March 09, 2021 @10:45PM (#26407519)
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).

Re:Why asynchronous Rust doesn't work by lalaithion on Wednesday March 10, 2021 @01:09AM (#26408311)
I mean, you can always just use an async crate and use async_std::task::block_on.
Re:Why asynchronous Rust doesn't work by boulos on Wednesday March 10, 2021 @01:22AM (#26408386)
Only if no other crate in your executable uses tokio or another executor, right?

Mixing executors is approximately fatal, AFAICT.

Re:Why asynchronous Rust doesn't work by cjg on Wednesday March 10, 2021 @01:59AM (#26408623)
I 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.

Re:Why asynchronous Rust doesn't work by boulos on Wednesday March 10, 2021 @12:47PM (#26413934)
That'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!".