Hacker News Reader

Comment by anderspitman | Hacker News Reader

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?

View on HN

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

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

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

Yes. Engineering is all about tradeoffs. This is a downside, but it is made up for by all the upsides.

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.

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

I heard that Zig sidesteps this, but I'm not aware of the details.

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.

Reply on news.ycombinator.com