4 ms·

1) Just use Tokio and libraries that support it. 2) spawn_blocking is your friend.

by trevyn 4y ago

capableweb 4y ago
> Just use Tokio and libraries that support it. Yeah, that's the problem :) Not all libraries I want to use, uses Tokio. What about those? Was that really the plan with async in Rust, that I'll get to chose between two ecosystems and if I chose one, I cannot use the other? Then just put Tokio in the standard library so there is at least some resemblance of consistency in the ecosystem.
- Ygg2 4y ago
  I have experienced this without any need for async. This is just lack of standardization. Same story can happen with time/decimals/database drivers. However pulling it into std would probably kill the library because backwards compatibility guarantees.
  - sanxiyn 4y ago
    Tokio is 1.0 since 2020 and they declared to maintain backwards compatibility for a minimum of 5 years. Tokio already made backwards compatibility guarantees and it hasn't been killed so far.
    - carllerche 4y ago
      It isn't a question of backwards compatibility, it is just way easier to iterate / evolve in a crate than it is in stdlib. For example, Tokio has the concept of "unstable" features, which have stronger stability guarantees than Rust nightly. First, you can use them with the stable rust compiler, second we guarantee that unstable features will not break across patch releases. This may seem small, but it lets us experiment with new functionality and get real world usage. Many of our users cannot use Rust nightly but can use Tokio unstable features.
    - Ygg2 4y ago
      Yeah carlleche nailed it. `std` is where libs go to die in Python sense. I didn't imply anything about Tokio. I just wish some libs didn't need to be bikeshedded (like async runtime, time, decimal, etc.)
- pornel 4y ago
  Which library? AFAIK there are no libraries that aren't compatible with tokio or without a direct tokio equivalent. The sad reality is that tokio dominates so hard that it's pointless to even try any other runtime.
  - capableweb 4y ago
    Library using async-std instead of tokio for example, which there are plenty out there. Search on crates.io and you'll see. Many support tokio nowadays, but there are still some out there that doesn't. And because of the closed nature of Rust libraries, it's not easy to patch it in there without having to fork the library.
    - pornel 4y ago
      I'm very familiar with the crates ecosystem (I run https://lib.rs https://lib.rs). I know there are libraries for async-std specifically, but my point is that AFAIK all of them have equivalents for tokio, e.g. you can't use `surf` with tokio, but there's `reqwest` and others. I'm not aware of any "killer app" existing that would be forcing anyone to use async-std (and if there was one, it'd get forked and converted to tokio ;) The lack of interoperability between runtimes creates a winner-takes-all situation, which creates a vicious cycle for async-std: fewer people use it, so it has fewer crates supporting it, so it's harder to write software depending on it, so fewer people use it. If you're bothered by the runtime fragmentation situation, use tokio. Fragmentation doesn't exist for tokio users (there are 10 tokio crates for every 1 async-std crate).

1) Just use Tokio and libraries that support it. 2) spawn_blocking is your friend.

by trevyn 4y ago

1) Just use Tokio and libraries that support it. 2) spawn_blocking is your friend.

> Just use Tokio and libraries that support it. Yeah, that's the problem :) Not all libraries I want to use, uses Tokio. What about those? Was that really the plan with async in Rust, that I'll get to chose between two ecosystems and if I chose one, I cannot use the other? Then just put Tokio in the standard library so there is at least some resemblance of consistency in the ecosystem.

Ygg2 4y ago
I have experienced this without any need for async. This is just lack of standardization. Same story can happen with time/decimals/database drivers. However pulling it into std would probably kill the library because backwards compatibility guarantees.
- sanxiyn 4y ago
  Tokio is 1.0 since 2020 and they declared to maintain backwards compatibility for a minimum of 5 years. Tokio already made backwards compatibility guarantees and it hasn't been killed so far.
  - carllerche 4y ago
    It isn't a question of backwards compatibility, it is just way easier to iterate / evolve in a crate than it is in stdlib. For example, Tokio has the concept of "unstable" features, which have stronger stability guarantees than Rust nightly. First, you can use them with the stable rust compiler, second we guarantee that unstable features will not break across patch releases. This may seem small, but it lets us experiment with new functionality and get real world usage. Many of our users cannot use Rust nightly but can use Tokio unstable features.
  - Ygg2 4y ago
    Yeah carlleche nailed it. `std` is where libs go to die in Python sense. I didn't imply anything about Tokio. I just wish some libs didn't need to be bikeshedded (like async runtime, time, decimal, etc.)
pornel 4y ago
Which library? AFAIK there are no libraries that aren't compatible with tokio or without a direct tokio equivalent. The sad reality is that tokio dominates so hard that it's pointless to even try any other runtime.
- capableweb 4y ago
  Library using async-std instead of tokio for example, which there are plenty out there. Search on crates.io and you'll see. Many support tokio nowadays, but there are still some out there that doesn't. And because of the closed nature of Rust libraries, it's not easy to patch it in there without having to fork the library.
  - pornel 4y ago
    I'm very familiar with the crates ecosystem (I run https://lib.rs https://lib.rs). I know there are libraries for async-std specifically, but my point is that AFAIK all of them have equivalents for tokio, e.g. you can't use `surf` with tokio, but there's `reqwest` and others. I'm not aware of any "killer app" existing that would be forcing anyone to use async-std (and if there was one, it'd get forked and converted to tokio ;) The lack of interoperability between runtimes creates a winner-takes-all situation, which creates a vicious cycle for async-std: fewer people use it, so it has fewer crates supporting it, so it's harder to write software depending on it, so fewer people use it. If you're bothered by the runtime fragmentation situation, use tokio. Fragmentation doesn't exist for tokio users (there are 10 tokio crates for every 1 async-std crate).