4 ms·

Hi! Tokio maintainer here. I'm surprised (in a good way) to see this posted to HN today. Nothing big is happening this week. That said, I'm always happy to ans

Hi! Tokio maintainer here. I'm surprised (in a good way) to see this posted to HN today. Nothing big is happening this week. That said, I'm always happy to answer questions.

onei 6y ago
One of the things that puts me off investing in Rust day-to-day is the lack of v1 packages in areas like this. I notice I'm not alone based on the results of the annual Rust survey. What do you imagine v1 will look like for Tokio compared to today and when would you envisage it landing?
- carllerche 6y ago
  We're aiming for 1.0 by Q3 2020. I wrote a bit about it here: https://tokio.rs/blog/2019-11-tokio-0-2/#a-roadmap-to-1-0 https://tokio.rs/blog/2019-11-tokio-0-2/#a-roadmap-to-1-0 That said, io_uring may end up impacting that target by a little bit. I understand the sentiment re v1. In reality, Tokio v0.1 was pretty much 1.0. We never cut 1.0 because async/await was in the works and it was unclear when it would be released. Now that async/await is out, 0.2 was a big change. We need some time to stabilize our APIs and collect user feedback. This process is happening now and going well.
  - carlmr 6y ago
    As someone who has dabbled in Rust, I think the Rustaceans are just too careful to bump something up to v1 before it's near perfect. In other languages the package ecosystem looks more mature because people are less careful in bumping up numbers.
    - carllerche 6y ago
      You aren't wrong. In hindsight, we should have shipped 1.0 a year or so after v0.1. I don't think we can ship 2.0 now. v0.3 is going to happen soon to fix errors in v0.2. async/await in Rust is very new. We are still figuring things out.
    - naasking 6y ago
      I'm sure they look more mature, but they might leave a bad impression. Rust already has "bad PR" with the borrow checker, so libraries being more conservative before bumping versions might work in its favour. Otherwise you might get a bad impression from the language and apparently immature libraries.
      - larntz 6y ago
        For me the borrow checker is what I find interesting about rust. I wouldn't call it bad pr.
        naasking 6y ago
        The people talking about it generally complain about it. Those comfortable with it generally aren't talking about it. I don't know what else to call that than bad PR. Just the nature of the beast.
  - michael_j_ward 6y ago
    Have you discussed elsewhere about io_uring plans? It isn't mentioned at all in the linked roadmap
    - carllerche 6y ago
      We are still figuring that out. When I wrote that post, uring was not yet working with sockets. Things have changed. We are exploring the space.
  - andrenth 6y ago
    Is there anywhere I can read about the plans for io_uring integration?
- pornel 6y ago
  BTW, Rust ecosystem has a fear of calling things 1.0. In the Rust world "1.0" often doesn't mean the first stable release, but more like "done". There are plenty of crates that are stable and production-ready, but with 0.x versions. In some cases ironically authors don't want to bump the version to 1.0, because the crates are so widely used and stable, that the mere version bump would be an unnecessarily big change (e.g. the most used libc crate will likely stay as v0.2 forever).
- remram 6y ago
  async-std, their main competitor, is 1.5.0
vasilakisfil 6y ago
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! Tokio maintainer here. I'm surprised (in a good way) to see this posted to HN today. Nothing big is happening this week. That said, I'm always happy to answer questions.

onei 6y ago

One of the things that puts me off investing in Rust day-to-day is the lack of v1 packages in areas like this. I notice I'm not alone based on the results of the annual Rust survey. What do you imagine v1 will look like for Tokio compared to today and when would you envisage it landing?

carllerche 6y ago
We're aiming for 1.0 by Q3 2020. I wrote a bit about it here: https://tokio.rs/blog/2019-11-tokio-0-2/#a-roadmap-to-1-0 https://tokio.rs/blog/2019-11-tokio-0-2/#a-roadmap-to-1-0 That said, io_uring may end up impacting that target by a little bit. I understand the sentiment re v1. In reality, Tokio v0.1 was pretty much 1.0. We never cut 1.0 because async/await was in the works and it was unclear when it would be released. Now that async/await is out, 0.2 was a big change. We need some time to stabilize our APIs and collect user feedback. This process is happening now and going well.
- carlmr 6y ago
  As someone who has dabbled in Rust, I think the Rustaceans are just too careful to bump something up to v1 before it's near perfect. In other languages the package ecosystem looks more mature because people are less careful in bumping up numbers.
  - carllerche 6y ago
    You aren't wrong. In hindsight, we should have shipped 1.0 a year or so after v0.1. I don't think we can ship 2.0 now. v0.3 is going to happen soon to fix errors in v0.2. async/await in Rust is very new. We are still figuring things out.
  - naasking 6y ago
    I'm sure they look more mature, but they might leave a bad impression. Rust already has "bad PR" with the borrow checker, so libraries being more conservative before bumping versions might work in its favour. Otherwise you might get a bad impression from the language and apparently immature libraries.
    - larntz 6y ago
      For me the borrow checker is what I find interesting about rust. I wouldn't call it bad pr.
      - naasking 6y ago
        The people talking about it generally complain about it. Those comfortable with it generally aren't talking about it. I don't know what else to call that than bad PR. Just the nature of the beast.
- michael_j_ward 6y ago
  Have you discussed elsewhere about io_uring plans? It isn't mentioned at all in the linked roadmap
  - carllerche 6y ago
    We are still figuring that out. When I wrote that post, uring was not yet working with sockets. Things have changed. We are exploring the space.
- andrenth 6y ago
  Is there anywhere I can read about the plans for io_uring integration?
pornel 6y ago
BTW, Rust ecosystem has a fear of calling things 1.0. In the Rust world "1.0" often doesn't mean the first stable release, but more like "done". There are plenty of crates that are stable and production-ready, but with 0.x versions. In some cases ironically authors don't want to bump the version to 1.0, because the crates are so widely used and stable, that the mere version bump would be an unnecessarily big change (e.g. the most used libc crate will likely stay as v0.2 forever).
remram 6y ago
async-std, their main competitor, is 1.5.0

vasilakisfil 6y ago

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