3 ms·

what's the case with async-std? Do the tokio devs have meetings with async-std regarding common problems they are facing, and is there any chance of merging tho

what's the case with async-std? Do the tokio devs have meetings with async-std regarding common problems they are facing, and is there any chance of merging those 2 projects, since in my humble opinion, seems like they solve the same problem pretty much ? edit: my question may not be formatted correctly, but basically I am asking whether there is cooperation between the 2 projects, or they are competing each other

carllerche 6y ago
Great question. I'm not thinking about competing. All I care about is users and building a great library. I think the best way to advance the state of the ecosystem is by experimenting and shipping improvements. IMO Ideas are best shared as working code. The Tokio team has been very active on that front. Recently, we've shipped a new strategy to improve the cooperative scheduler (https://tokio.rs/blog/2020-04-preemption/ https://tokio.rs/blog/2020-04-preemption/), and a bunch of other new utilities (https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.12 https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.12, https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.11 https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.11). Standardization can be extracted once proven. This is how `std::future` came to be.
zamalek 6y ago
The purpose of tokio was to add asynchronous support to Rust in the absence of async features (it predates them). It has since added std-like async interfaces. It is the most mature. async-std aims to do that last sentence as cleanly as possible, without having to support a legacy interface. I found it builds faster because of that and that's why I chose it. smol (the new kid in the block) aims to async-ify network types by simply wrapping them in Async<T>. It also aims to be as few lines of code as possible. They are all different approaches to the same problem. The ability to experiment with different approaches is precisely why Rust doesn't have a prescribed async runtime (or prescribed error types, or many other things). If merely solving the problem is all you care about, pick tokio. It should be able to use async-std crates, but async-std can't use it. smol can use anything but is a bit unproven.
stjepang 6y ago
Hi there, thought I might chime in as someone who used to work on tokio and is now working on async-std and smol. :) A month ago I wrote a blog post about the evolution of async Rust and its async runtimes. Hopefully this answers your questions! https://stjepang.github.io/2020/04/03/why-im-building-a-new-async-runtime.html https://stjepang.github.io/2020/04/03/why-im-building-a-new-...
- mwcampbell 6y ago
  Why is "does not depend on mio" a desirable feature? Do you find mio too complex? Or are you just trying to minimize dependence on other crates on principle for this project?

carllerche 6y ago

Great question. I'm not thinking about competing. All I care about is users and building a great library. I think the best way to advance the state of the ecosystem is by experimenting and shipping improvements. IMO Ideas are best shared as working code. The Tokio team has been very active on that front. Recently, we've shipped a new strategy to improve the cooperative scheduler (https://tokio.rs/blog/2020-04-preemption/ https://tokio.rs/blog/2020-04-preemption/), and a bunch of other new utilities (https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.12 https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.12, https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.11 https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.11). Standardization can be extracted once proven. This is how `std::future` came to be.

zamalek 6y ago

The purpose of tokio was to add asynchronous support to Rust in the absence of async features (it predates them). It has since added std-like async interfaces. It is the most mature. async-std aims to do that last sentence as cleanly as possible, without having to support a legacy interface. I found it builds faster because of that and that's why I chose it. smol (the new kid in the block) aims to async-ify network types by simply wrapping them in Async<T>. It also aims to be as few lines of code as possible. They are all different approaches to the same problem. The ability to experiment with different approaches is precisely why Rust doesn't have a prescribed async runtime (or prescribed error types, or many other things). If merely solving the problem is all you care about, pick tokio. It should be able to use async-std crates, but async-std can't use it. smol can use anything but is a bit unproven.

stjepang 6y ago

Hi there, thought I might chime in as someone who used to work on tokio and is now working on async-std and smol. :) A month ago I wrote a blog post about the evolution of async Rust and its async runtimes. Hopefully this answers your questions! https://stjepang.github.io/2020/04/03/why-im-building-a-new-async-runtime.html https://stjepang.github.io/2020/04/03/why-im-building-a-new-...

mwcampbell 6y ago
Why is "does not depend on mio" a desirable feature? Do you find mio too complex? Or are you just trying to minimize dependence on other crates on principle for this project?