4 ms·

Top problem for me as a relative Rust beginner (couple of months of Rust) right now: Mixing async/sync code. The ecosystem seems very split across how to handle

Top problem for me as a relative Rust beginner (couple of months of Rust) right now: Mixing async/sync code. The ecosystem seems very split across how to handle things, and async code doesn't work well with sync code, and vice-versa. Some libraries assume runtimes to be available, others that there is no runtime. One async library is incompatible with some other async libraries because they use different runtimes. It's a whole mess. Edit: also, "features" are sometimes a headache. Just spent ~one day trying to figure out how to build cross-platform static binaries when bunch of libraries depend on openssl-lib. Ended up using "features" to disable it and enable "rusttls" instead, but had to also disable the default features and figure out exactly which ones I needed.

trevyn 4y ago
1) Just use Tokio and libraries that support it. 2) spawn_blocking is your friend.
- 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).
tester756 4y ago
>Mixing async/sync code. So Rust has the same problem as C# has that mixing async/sync may have some quirks and edge cases? and you have lengthy guides how&when to use one method[0] [0] https://devblogs.microsoft.com/dotnet/configureawait-faq/ https://devblogs.microsoft.com/dotnet/configureawait-faq/
- pjmlp 4y ago
  Rust is worse, because at least .NET doesn't require going hunting for an async runtime that is compatible with all 3rd party dependencies, and all graphical debuggers know how to step through async code.
epage 4y ago
> Edit: also, "features" are sometimes a headache. Just spent ~one day trying to figure out how to build cross-platform static binaries when bunch of libraries depend on openssl-lib. Ended up using "features" to disable it and enable "rusttls" instead, but had to also disable the default features and figure out exactly which ones I needed. One big usability improvement for features is the addition of cargo-add which can be help in editing features with its table of whats activated. The next is making it more explicit which optional dependencies are optional features but this requires crates to update to rust 1.60 and make some changes. Something we are discussing is changing `defaut-features = false` and re-adding what you want to opting out of each default feature. With the current behavior it can be a pain to re-enable what you want and crates can't move existing behavior to a feature without a breaking change.
- shepmaster 4y ago
  > Something we are discussing is changing `defaut-features = false` I’d be generally in favor of such a change as this is what I use for all of my projects when I start out. I find it much more comfortable to deliberately opt in to things that I need as I find that I need them. The biggest pain point I’ve experienced is for features that are performance based when I am writing an application instead of a library. It’s hard to know that those exist, and that I probably do want them, I just don’t require them.
  - epage 4y ago
    Sorry, I was meaning the opposite. We'd be deprecating it and making it unavailable in future editions. Instead you have to opt out of each default feature.
- rascul 4y ago
  > One big usability improvement for features is the addition of cargo-add which can be help in editing features with its table of whats activated. This made feature discovery much easier for me. Previously, I would often inspect the Cargo.toml for crates I wanted to use to see what features might or might not be useful, now it's all done with 'cargo add'.

trevyn 4y ago

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

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).

tester756 4y ago

>Mixing async/sync code. So Rust has the same problem as C# has that mixing async/sync may have some quirks and edge cases? and you have lengthy guides how&when to use one method[0] [0] https://devblogs.microsoft.com/dotnet/configureawait-faq/ https://devblogs.microsoft.com/dotnet/configureawait-faq/

pjmlp 4y ago
Rust is worse, because at least .NET doesn't require going hunting for an async runtime that is compatible with all 3rd party dependencies, and all graphical debuggers know how to step through async code.

epage 4y ago

> Edit: also, "features" are sometimes a headache. Just spent ~one day trying to figure out how to build cross-platform static binaries when bunch of libraries depend on openssl-lib. Ended up using "features" to disable it and enable "rusttls" instead, but had to also disable the default features and figure out exactly which ones I needed. One big usability improvement for features is the addition of cargo-add which can be help in editing features with its table of whats activated. The next is making it more explicit which optional dependencies are optional features but this requires crates to update to rust 1.60 and make some changes. Something we are discussing is changing `defaut-features = false` and re-adding what you want to opting out of each default feature. With the current behavior it can be a pain to re-enable what you want and crates can't move existing behavior to a feature without a breaking change.

shepmaster 4y ago
> Something we are discussing is changing `defaut-features = false` I’d be generally in favor of such a change as this is what I use for all of my projects when I start out. I find it much more comfortable to deliberately opt in to things that I need as I find that I need them. The biggest pain point I’ve experienced is for features that are performance based when I am writing an application instead of a library. It’s hard to know that those exist, and that I probably do want them, I just don’t require them.
- epage 4y ago
  Sorry, I was meaning the opposite. We'd be deprecating it and making it unavailable in future editions. Instead you have to opt out of each default feature.
rascul 4y ago
> One big usability improvement for features is the addition of cargo-add which can be help in editing features with its table of whats activated. This made feature discovery much easier for me. Previously, I would often inspect the Cargo.toml for crates I wanted to use to see what features might or might not be useful, now it's all done with 'cargo add'.