3 ms·

As a Rust user, I have to say that it was an incredibly confusing feature. Not because of the technical decisions behind async/await, but because of the async

As a Rust user, I have to say that it was an incredibly confusing feature. Not because of the technical decisions behind async/await, but because of the async ecosystem, especially the runtimes. Picture a Rust user when the feature came: - You can use it with future combinators! - No, actually, use it with a macro library that almost works but not really. - Here is Tokio (with a lot of moving parts). - Wait, async std is much simpler (again, almost seems to work but not really). - Wait, here is Smol, which is truly simpler (or at least smaller but not used). => You get "async fatigue." I can understand the position: let's not commit to anything before seeing what sticks on the wall. It might have worked for Serde (even that is debatable by some). But as a user, it's hard to follow, and you get the impression that this feature is not the stable foundation you can build on.

littlestymaar 3y ago
Honestly, it gets better once you learn to stop worrying and love tokio. I don't like the idea of having a single framework shaping up the entire Rust ecosystem, but at the same time once you just jump the tokio ship, everything just works out of the box and you don't have to worry. lots I wonder what are you referring to when talking about “lots of moving parts” when tokio has reached 1.0 three years ago and been pretty much stable since then.
- dgacmu 3y ago
  Tokio is awesome and I end up using it on almost all of my server projects. But, particularly for library developers, one reason not to just jump on tokio and instead strive for (some, reasonable) compatibility across executors is the embedded world - async is an amazing match for programming tiny microprocessors because it provides an elegant syntactic sugar for all of those little interacting state machines, you would otherwise write, but you don't want a heavyweight thread-based executor to be mandatory. (The embassy embedded framework for rust is an example of this. It doesn't yet have as wide support as some non-async frameworks but for the things that it's compatible with, it's an absolute delight.)
  - zbentley 3y ago
    > heavyweight thread-based executor While it's not the default, Tokio is usable in full without threads using the current-thread executor: https://docs.rs/tokio/latest/tokio/runtime/index.html#current-thread-scheduler https://docs.rs/tokio/latest/tokio/runtime/index.html#curren...
- egnehots 3y ago
  The tokio ecosystem is also a world of its own. Tokio internals are plentiful and more complex than in other runtimes. But the common difficulty is choosing what to use for an http server. - hyper? just an http library but bring your own boilerplate? - actix web? it was quite opiniated and there was some drama from its main author. - axum? wait that seems to be the latest consensus actually. And that's just the remaining popular choices.
  - spoiler 3y ago
    Honesty, Axum is a breeze to use
  - foolswisdom 3y ago
    Axum looks interesting, haven't seen that before. I've been using Rocket.
  - paholg 3y ago
    A nicety of axum is it uses hyper under the hood.
- yencabulator 3y ago
  By fixing yourself into the current Tokio API, you're locking your app into some decisions that might not be the best. https://github.com/tokio-rs/tokio-uring/ https://github.com/tokio-rs/tokio-uring/ https://www.datadoghq.com/blog/engineering/introducing-glommio/ https://www.datadoghq.com/blog/engineering/introducing-glomm... https://itnext.io/modern-storage-is-plenty-fast-it-is-the-apis-that-are-bad-6a68319fbc1a https://itnext.io/modern-storage-is-plenty-fast-it-is-the-ap... https://news.ycombinator.com/item?id=25220892 https://news.ycombinator.com/item?id=25220892 https://www.reddit.com/r/rust/comments/k16j6x/modern_storage_is_plenty_fast_it_is_the_apis_that/ https://www.reddit.com/r/rust/comments/k16j6x/modern_storage... https://www.reddit.com/r/programming/comments/k0yyk7/modern_storage_is_plenty_fast_it_is_the_apis_that/ https://www.reddit.com/r/programming/comments/k0yyk7/modern_... https://www.youtube.com/watch?v=PbgTyCSDPrs https://www.youtube.com/watch?v=PbgTyCSDPrs
  - littlestymaar 3y ago
    > By fixing yourself into the current Tokio API, you're locking your app into some decisions that might not be the best. The impact of tokio on your app's code base isn't actually particularly big, and it wouldn't be too much trouble to change (the interface of other runtimes is very close to tokio's AFAIK). the main issue is the ecosystem: most of it is using tokio already so opting out of tokio also means cornering yourself in a place where there's little available external libraries to use. The ecosystem strong ties with tokio isn't a good thing, and I wish there were ways to make things generic over the runtime, but it's not an application developer's decision in any case.
    - yencabulator 3y ago
      You didn't really look at the links. Other ways of arranging the computation & I/O, like the thread-per-core model of glommio and io_uring, fundamentally change the API. There's even a second implementation of Tokio with an API different from the first one!
      - littlestymaar 3y ago
        Sorry I did not read your 6 links… (3 out of 6 are already grey though, which means I already got there before) > Other ways of arranging the computation & I/O, like the thread-per-core model of glommio and io_uring, fundamentally change the API. There's even a second implementation of Tokio with an API different from the first one! It's an incompatible API in the sense that you need to update your code, but it doesn't require deep re-architecture work or anything (going from thread-per-core like glomio to tokio would be harder for instance, because then you'd need your futures to be Send).

littlestymaar 3y ago

Honestly, it gets better once you learn to stop worrying and love tokio. I don't like the idea of having a single framework shaping up the entire Rust ecosystem, but at the same time once you just jump the tokio ship, everything just works out of the box and you don't have to worry. lots I wonder what are you referring to when talking about “lots of moving parts” when tokio has reached 1.0 three years ago and been pretty much stable since then.

dgacmu 3y ago
Tokio is awesome and I end up using it on almost all of my server projects. But, particularly for library developers, one reason not to just jump on tokio and instead strive for (some, reasonable) compatibility across executors is the embedded world - async is an amazing match for programming tiny microprocessors because it provides an elegant syntactic sugar for all of those little interacting state machines, you would otherwise write, but you don't want a heavyweight thread-based executor to be mandatory. (The embassy embedded framework for rust is an example of this. It doesn't yet have as wide support as some non-async frameworks but for the things that it's compatible with, it's an absolute delight.)
- zbentley 3y ago
  > heavyweight thread-based executor While it's not the default, Tokio is usable in full without threads using the current-thread executor: https://docs.rs/tokio/latest/tokio/runtime/index.html#current-thread-scheduler https://docs.rs/tokio/latest/tokio/runtime/index.html#curren...
egnehots 3y ago
The tokio ecosystem is also a world of its own. Tokio internals are plentiful and more complex than in other runtimes. But the common difficulty is choosing what to use for an http server. - hyper? just an http library but bring your own boilerplate? - actix web? it was quite opiniated and there was some drama from its main author. - axum? wait that seems to be the latest consensus actually. And that's just the remaining popular choices.
- spoiler 3y ago
  Honesty, Axum is a breeze to use
- foolswisdom 3y ago
  Axum looks interesting, haven't seen that before. I've been using Rocket.
- paholg 3y ago
  A nicety of axum is it uses hyper under the hood.
yencabulator 3y ago
By fixing yourself into the current Tokio API, you're locking your app into some decisions that might not be the best. https://github.com/tokio-rs/tokio-uring/ https://github.com/tokio-rs/tokio-uring/ https://www.datadoghq.com/blog/engineering/introducing-glommio/ https://www.datadoghq.com/blog/engineering/introducing-glomm... https://itnext.io/modern-storage-is-plenty-fast-it-is-the-apis-that-are-bad-6a68319fbc1a https://itnext.io/modern-storage-is-plenty-fast-it-is-the-ap... https://news.ycombinator.com/item?id=25220892 https://news.ycombinator.com/item?id=25220892 https://www.reddit.com/r/rust/comments/k16j6x/modern_storage_is_plenty_fast_it_is_the_apis_that/ https://www.reddit.com/r/rust/comments/k16j6x/modern_storage... https://www.reddit.com/r/programming/comments/k0yyk7/modern_storage_is_plenty_fast_it_is_the_apis_that/ https://www.reddit.com/r/programming/comments/k0yyk7/modern_... https://www.youtube.com/watch?v=PbgTyCSDPrs https://www.youtube.com/watch?v=PbgTyCSDPrs
- littlestymaar 3y ago
  > By fixing yourself into the current Tokio API, you're locking your app into some decisions that might not be the best. The impact of tokio on your app's code base isn't actually particularly big, and it wouldn't be too much trouble to change (the interface of other runtimes is very close to tokio's AFAIK). the main issue is the ecosystem: most of it is using tokio already so opting out of tokio also means cornering yourself in a place where there's little available external libraries to use. The ecosystem strong ties with tokio isn't a good thing, and I wish there were ways to make things generic over the runtime, but it's not an application developer's decision in any case.
  - yencabulator 3y ago
    You didn't really look at the links. Other ways of arranging the computation & I/O, like the thread-per-core model of glommio and io_uring, fundamentally change the API. There's even a second implementation of Tokio with an API different from the first one!
    - littlestymaar 3y ago
      Sorry I did not read your 6 links… (3 out of 6 are already grey though, which means I already got there before) > Other ways of arranging the computation & I/O, like the thread-per-core model of glommio and io_uring, fundamentally change the API. There's even a second implementation of Tokio with an API different from the first one! It's an incompatible API in the sense that you need to update your code, but it doesn't require deep re-architecture work or anything (going from thread-per-core like glomio to tokio would be harder for instance, because then you'd need your futures to be Send).