5 ms·

How's async looking in Rust these days? About a year ago I wrote one service that's in production. I ended up doing a lot of the futures stuff by hand. Never re

How's async looking in Rust these days? About a year ago I wrote one service that's in production. I ended up doing a lot of the futures stuff by hand. Never really understood how the error mapping/conversions worked, and usually just fiddled with them until it compiled. I remember the docs being decent, but there wasn't a single book/site that had everything in a comprehensive and approachable manner. In spite of all that, the service has chugged along pretty nicely. Ultimately I've just been more productive in Go for the time being, but I remember definitely see the potential down the road for great things. Has async/await permeated the ecosystem? Is the book more fleshed out?

carllerche 7y ago
It gets better every day. async/await is relatively new (stabilized end of last year). All the misc libs in the Tokio stack have been updated. There is Tonic for gRPC, Hyper/reqwest/warp for HTTP, ... these all work with async/await now. For docs, there are some now and I expect it to improve a lot throughout the year. We also just posted mini-redis as a larger "real world" example: https://github.com/tokio-rs/mini-redis https://github.com/tokio-rs/mini-redis
- anderspitman 7y ago
  Very nice. I used warp (awesome) for my service. Maybe I should update it to use async/await as an exercise.
tick_tock_tick 7y ago
It's better but it suffers from the same poison aspect all async/await implementations do. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
- steveklabnik 7y ago
  Yes. Engineering is all about tradeoffs. This is a downside, but it is made up for by all the upsides.
- naasking 7y ago
  Can't say I find that argument all that compelling. Using the logic from that article, functions that perform side-effects have a different colour from those that don't, therefore we should prevent all functions with side-effects to enable better interoperation? I suspect the author and most other programmers might have some disagreements with their new monadic overlords. The point is that "colour" is introduced to make a meaningful distinction in order to achieve a desirable property. He's enamored by Go which erases this distinction, but it does so by giving up nearly all of the benefits of the event-driven model: very small captured state for resuming the continuation.
  - lmm 7y ago
    > Using the logic from that article, functions that perform side-effects have a different colour from those that don't, therefore we should prevent all functions with side-effects to enable better interoperation? The argument is the reverse: it's too hard to explicitly manage side effects, so we should make our functions implicitly, pervasively side-effecting. E.g. allowing any function to throw an exception without declaring this in their signature is widely agreed to be a better approach than Java-style checked exceptions; the argument goes that we should also allow any function to be async without declaring this in its signature. (I think there's some merit to the argument in languages that aren't powerful enough to express functions that are polymorphic over async-ness. Personally I use languages with higher-kinded types and then you get the best of both worlds: you have an explicit distinction between async and not, but you can write functions that work with both)
- faitswulff 7y ago
  I heard that Zig sidesteps this, but I'm not aware of the details.
- hobofan 7y ago
  I very much disagree that it does. The core pitfalls are pretty specific to JS, and don't exist in Rust. In Rust you can easily call an "async colored" function from a "sync colored" one by running it to completion with the executor of your choice. With that you can prevent async bleeding all over your codebase.

carllerche 7y ago

It gets better every day. async/await is relatively new (stabilized end of last year). All the misc libs in the Tokio stack have been updated. There is Tonic for gRPC, Hyper/reqwest/warp for HTTP, ... these all work with async/await now. For docs, there are some now and I expect it to improve a lot throughout the year. We also just posted mini-redis as a larger "real world" example: https://github.com/tokio-rs/mini-redis https://github.com/tokio-rs/mini-redis

anderspitman 7y ago
Very nice. I used warp (awesome) for my service. Maybe I should update it to use async/await as an exercise.

tick_tock_tick 7y ago

It's better but it suffers from the same poison aspect all async/await implementations do. https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

steveklabnik 7y ago
Yes. Engineering is all about tradeoffs. This is a downside, but it is made up for by all the upsides.
naasking 7y ago
Can't say I find that argument all that compelling. Using the logic from that article, functions that perform side-effects have a different colour from those that don't, therefore we should prevent all functions with side-effects to enable better interoperation? I suspect the author and most other programmers might have some disagreements with their new monadic overlords. The point is that "colour" is introduced to make a meaningful distinction in order to achieve a desirable property. He's enamored by Go which erases this distinction, but it does so by giving up nearly all of the benefits of the event-driven model: very small captured state for resuming the continuation.
- lmm 7y ago
  > Using the logic from that article, functions that perform side-effects have a different colour from those that don't, therefore we should prevent all functions with side-effects to enable better interoperation? The argument is the reverse: it's too hard to explicitly manage side effects, so we should make our functions implicitly, pervasively side-effecting. E.g. allowing any function to throw an exception without declaring this in their signature is widely agreed to be a better approach than Java-style checked exceptions; the argument goes that we should also allow any function to be async without declaring this in its signature. (I think there's some merit to the argument in languages that aren't powerful enough to express functions that are polymorphic over async-ness. Personally I use languages with higher-kinded types and then you get the best of both worlds: you have an explicit distinction between async and not, but you can write functions that work with both)
faitswulff 7y ago
I heard that Zig sidesteps this, but I'm not aware of the details.
hobofan 7y ago
I very much disagree that it does. The core pitfalls are pretty specific to JS, and don't exist in Rust. In Rust you can easily call an "async colored" function from a "sync colored" one by running it to completion with the executor of your choice. With that you can prevent async bleeding all over your codebase.