Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why asynchronous Rust doesn't work

theta.eu.org

Post reply on HN
Print view View original

91–100 of 499 posts

Re: Why asynchronous Rust doesn't work

#91

Post by kibwen »

shmerl wrote: post #70
newpavlov wrote: post #45

Earlier quoted context omitted.

Yes, you can encode state machines manually, but it will be FAR less ergonomic than the async syntax. Rust has started with a library-based approach, but it was... not great. Async code was littered with and_then methods and it was really close to the infamous JS callback hell. The ergonomic improvements which async/await brings is essentially a raison d'être for incorporating this functionality into the language.

Can't Rust come up with a new syntax (that matches io_uring idea better) and deprecate the old one? Or simply replace the implementation keeping the old syntax if it's semantically the same?

It could, although I highly doubt that any deficiencies with the current implementation of async/await are so severe as to warrant anything so dramatic.

Re: Why asynchronous Rust doesn't work

#92

Post by KingOfCoders »

Rust chose to build on Futures and async.

Author wants to have node style callbacks

"I’d like to make a simple function that does some work in the background, and lets us know when it’s done by running another function with the results of said background work."

Author is unhappy with Rust.

What I would like to have out of Rust async runtimes is the Go version: Coroutines and moving waiting IO automatically to a thread queue.

Re: Why asynchronous Rust doesn't work

#93

Post by newpavlov »

comex wrote: post #75
newpavlov wrote: post #37

A bigger problem in my opinion is that Rust has chosen to follow the poll-based model (you can say that it was effectively designed around epoll), while the completion-based one (e.g. io-uring and IOCP) with high probability will be the way of doing async in future (especially in the light of Spectre and Meltdown). Instead of carefully weighing advantages and disadvantages of both models, the decision was effectively…

> Instead of carefully weighing advantages and disadvantages of both models, the decision was effectively made on the ground of "we want to ship async support as soon as possible" [1]. That is not an accurate summary of that comment. withoutboats may have been complaining about someone trying to revisit the decision made in 2015-2016, but as the comment itself points out, there were good reasons for that decision. Ma…

>That is not an accurate summary of that comment.

How is to so, if he explicitly writes:

> Suggestions that we should revisit our underlying futures model are suggestions that we should revert back to the state we were in 3 or 4 years ago, and start over from that point. Trying to provide answers to these questions would be off-topic for this thread; the point is that answering them, and proving the answers correct, is work. What amounts to a solid decade of labor-years between the different contributors so far would have to be redone again.

How should I read it except like "we did the work on the poll-based model, so we don't want for the results to go down the drain in the case if the completion-based model will turn to be superior"?

I don't agree with your assertion regarding cyclic structures and the need of dynamic allocations in the completion-based model. Both models result in approximately the same cyclisity of task states, no wonders, since task states are effectively size-bound stacks. In both models you have more or less the same finite state machines. The only difference is in how those FSMs interact with runtime and in the fact that in the completion-based model you usually pass ownership of a task state part to runtime during task suspension. So you can not simply drop a task if you no longer need its results, you have to explicitly request its cancellation from runtime.

Re: Why asynchronous Rust doesn't work

#94

Post by KingOfCoders »

newpavlov wrote: post #37

A bigger problem in my opinion is that Rust has chosen to follow the poll-based model (you can say that it was effectively designed around epoll), while the completion-based one (e.g. io-uring and IOCP) with high probability will be the way of doing async in future (especially in the light of Spectre and Meltdown). Instead of carefully weighing advantages and disadvantages of both models, the decision was effectively…

The poll model has the advantage that you have control when async work starts and therefor is the more predictable model.

I guess that way it fits more the Rust philosophy.

Re: Why asynchronous Rust doesn't work

#95

Post by jstrong »

omginternets wrote: post #73
jstrong wrote: post #30

I've been primarily coding in rust since 2018. I never cared for async/await, and I've never used it. (at some point, coding event loops became very natural/comfortable for me, and I have no trouble writing "manual" epoll code with mio/mio_httpc). one nice thing about rust's async/await is, you don't have to use it, and if you don't, you don't pay for it in any way. sure, I run into crates that expect me to bring in…

Mmmyeah, they said this about python too...

rust has avoided many pitfalls that python fell into. one example is the way that rust 2015 edition code works seamlessly with rust 2018 edition code, unlike the python2 -> python3 debacle. another is cargo vs pip/poetry/this month's python package manager. so, using python as an example isn't very convincing to me.

Re: Why asynchronous Rust doesn't work

#96

Post by lmm »

_zhqs wrote: post #25
lmm wrote: post #13

Async isn't really the problem - the same issue pops up with error handling, with resource management, with anything where you want to pass functions around. The real problem is that Rust's ownership semantics and limited abstractions mean it doesn't really have first-class functions: there are three different function types and the language lacks the power to abstract over them, so you can't generally take an expres…

> anything where you want to pass functions around. You should read the article! The author goes into this in fascinating detail.

I did read the article; it's overly focused on async (especially the headline). The body quite correctly analyses the problem with functions, but misses that this is much more general than async; just adopting a different async model isn't a solution.

Re: Why asynchronous Rust doesn't work

#97

Post by [deleted] »

dwohnitmok wrote: post #63
stormbrew wrote: post #44

Earlier quoted context omitted.

> maybe it was a mistake to adopt an async paradigm from functional languages > I think Rust was right to pick Scala-style async I'm confused by this assertion. I'm more aware of procedural language origins of syntactic async/await than functional? The scala proposal in 2016 for async/await even cites C#'s design (which came in C# 5.0 in 2012) as an inspiration[1]. From there, it appears python and typescript added t…

> If anything, async-await feels like an extremely non-functional thing to begin with Futures/promises (they mean different things in different languages), like many other things, form monads. In fact async-await is a specialization of various monad syntactic sugars that try to eliminate long callback chains that commonly affect many different sorts of monads. Hence things like Haskell's do-notation are direct precur…

[deleted]

Re: Why asynchronous Rust doesn't work

#98

Post by 0xdeadfeed »

roca wrote: post #50
noncoml wrote: post #39

> And, as I said at the start, that makes me kinda sad, because I do actually like Rust. I think that’s the most important part of the article. People like Rust but it’s becoming more complex than C++. But unlike C++ it’s more difficult to pick and choose what you use. Rust’s death will be one by thousand cuts. “I really like the language but can’t justify all that complexity in my new small and simpke project” is wh…

It is in no danger of become as complex than C++. Nowhere near.

The pace it is going at, it’s not that far from it

Re: Why asynchronous Rust doesn't work

#100

Post by kibwen »

newpavlov wrote: post #62
eximius wrote: post #53

Earlier quoted context omitted.

Could Rust switch? More importantly, would a completion based model alleviate the problems mentioned?

Without introducing Rust 2? Highly unlikely. I should have worded my message more carefully. Completion-based model is not a silver bullet which would magically solve all problems (though I think it would help a bit with the async Drop problem). The problem is that Rust async was rushed without careful deliberation, which causes a number of problems without a clear solution in sight.

> The problem is that Rust async was rushed without careful deliberation

As someone who observed the process, this couldn't be further from the truth. Just because one disagrees with the conclusion does not mean that the conclusion was made in haste or in ignorance.

> Without introducing Rust 2? Highly unlikely.

This is incorrect. async/await is a leaf node on the feature tree; it is supported by other language features, but does not support any others. Deprecating or removing it in favor of a replacement would not be traumatic for the language itself (less so for the third-party async/await ecosystem, of course). But this scenario is overly dramatic: the benefits of a completion-based model are not so clear-cut as to warrant such actions.

Post reply on HN