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

291–300 of 499 posts

Re: Why asynchronous Rust doesn't work

#291

Post by newpavlov »

withoutboats2 wrote: post #277
newpavlov wrote: post #259

Earlier quoted context omitted.

Can you provide any public sources for that? From that I've seen Rust async story was always developed primarily around epoll.

Alex Crichton started with a completion based Future struct in 2015. It was even (unstable) in std in 1.0.0: https://doc.rust-lang.org/1.0.0/std/sync/struct.Future.html Our async IO model was based on the Linux industry standard (then and now) epoll, but that is not at all what drove the switch to a polling based model, and the polling based model presents no issues whatsoever with io-uring. You do not know what you…

>Our async IO model was based on the Linux industry standard (then and now) epoll, but that is not at all what drove the switch to a polling based model

Can you provide a link to a design document or at the very least to a discussion with motivation for this switch outside of the desire to be as compatible as possible with the "Linux industry standard"?

>the polling based model presents no issues whatsoever with io-uring

There are no issues with io-uring compatibility to such extent that you wrote about a whole blog post about those issues: https://boats.gitlab.io/blog/post/io-uring/

IIUC the best solutions right now are either to copy data around (bye-bye zero-cost) or to use another Pin-like awkward hack with executor-based buffer management, instead of using simple and familiar buffers which are part of a future state.

Re: Why asynchronous Rust doesn't work

#292

Post by the_duke »

jedisct1 wrote: post #263
johnnycerberus wrote: post #220

Earlier quoted context omitted.

In all this time, maestro Andrei Alexandrescu was right when he said Rust feels like it "skipped leg day" when it comes to concurrency and metaprogramming capabilities. Tim Sweeney was complaining about similar things, saying about Rust that is one step forward, one step backward. These problems will be evident at a later time, when it will be already too late. I will continue experimenting with Rust, but Zig seems t…

And Zap (scheduler for Zig) is already faster than Tokio. Zig and other recent languages have been invented after Rust and Go, so they could learn from them, while Rust had to experiment a lot in order to combine async with borrow checking. So, yes, the async situation in Rust is very awkward, and doing something beyond a Ping server is more complicated than it could be. But that’s what it takes to be a pioneer.

> And Zap (scheduler for Zig) is already faster than Tokio.

I'm not necessarily doubtful, tokio isn't the fastest implementation of a runtime.

But can you point to a non-trivial benchmark that shows this?

Performance claims should always come with a verifiable benchmark.

Re: Why asynchronous Rust doesn't work

#294

Post by heavenlyblue »

cjg wrote: post #166
noncoml wrote: post #156

Earlier quoted context omitted.

> Just because async is in the language, don't feel like you need to use it everywhere. Except that you will have to because no alternative library exist

It's easy to convert an async function into a blocking one. For example, you could use https://docs.rs/async-std/1.9.0/async_std/task/fn.block_on.h... So just use the async functions from the library synchronously if you want.

But you can't really do vice-versa.

Re: Why asynchronous Rust doesn't work

#295

Post by withoutboats2 »

newpavlov wrote: post #291
withoutboats2 wrote: post #277

Earlier quoted context omitted.

Alex Crichton started with a completion based Future struct in 2015. It was even (unstable) in std in 1.0.0: https://doc.rust-lang.org/1.0.0/std/sync/struct.Future.html Our async IO model was based on the Linux industry standard (then and now) epoll, but that is not at all what drove the switch to a polling based model, and the polling based model presents no issues whatsoever with io-uring. You do not know what you…

>Our async IO model was based on the Linux industry standard (then and now) epoll, but that is not at all what drove the switch to a polling based model Can you provide a link to a design document or at the very least to a discussion with motivation for this switch outside of the desire to be as compatible as possible with the "Linux industry standard"? >the polling based model presents no issues whatsoever with io-u…

https://aturon.github.io/blog/2016/09/07/futures-design/

The completion based futures that Alex started with were also based on epoll. The performance issues it presented had nothing to do any sort of impedence mismatch between a completion based future and epoll, because there is no impedence issue. You are confused.

Re: Why asynchronous Rust doesn't work

#296

Post by zbentley »

croes wrote: post #9

I don't know rust good enough but the article sounds like 'I can't write it like I want, therefore it's bad'. Couldn't he just pass a named function instead of an anonymous one?

No, he could not. The problem emerges when trying to use state (a database connection, in the author's example) in the callback function. That requires a closure (or a managed global, but that's not zero-cost).

Re: Why asynchronous Rust doesn't work

#297

Post by jedisct1 »

the_duke wrote: post #292
jedisct1 wrote: post #263

Earlier quoted context omitted.

And Zap (scheduler for Zig) is already faster than Tokio. Zig and other recent languages have been invented after Rust and Go, so they could learn from them, while Rust had to experiment a lot in order to combine async with borrow checking. So, yes, the async situation in Rust is very awkward, and doing something beyond a Ping server is more complicated than it could be. But that’s what it takes to be a pioneer.

> And Zap (scheduler for Zig) is already faster than Tokio. I'm not necessarily doubtful, tokio isn't the fastest implementation of a runtime. But can you point to a non-trivial benchmark that shows this? Performance claims should always come with a verifiable benchmark.

Check out @kingprotty's Twitter posts and Zig Show presentations.

Re: Why asynchronous Rust doesn't work

#298

Post by mutatio »

I can sympathize with the tone. I recently attempted to move to the latest `tokio-postgres` as the old synchronous version is no longer supported (the new synchronous version uses Tokio under the hood which plays havoc if you use with actix-web [two different executors]), the problem is I'm using it with CockroachDB which effectively requires transaction retries (for savepoints). I've yet to produce a ergonomic tx::retry wrapper that doesn't have lifetime issues (for primitives supporting Copy it's all good).

With the asyncification of the Rust ecosystem it does make life difficult. Maybe the Rust async implementation is fundamentally sound, but the user experience for non-trivial cases isn't quite there.

Re: Why asynchronous Rust doesn't work

#299

Post by roca »

sai_c wrote: post #232
roca wrote: post #224

Earlier quoted context omitted.

It is hard to stop people perceiving Rust as over-complex if they are motivated to perceive it as over-complex.

Yes, indeed. Yet, this is the problem to solve. I don't know if you are using Rust, but what would you say, why is that? Where does that motivation come from?

I've been developing mostly in Rust for the last five years. C++ for decades before that.

It is always comforting to dismiss something that you haven't made much effort to understand as unnecessarily overcomplex. I think we're all guilty of that at times.

Re: Why asynchronous Rust doesn't work

#300

Post by matdehaast »

withoutboats2 wrote: post #269
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…

This post is completely and totally wrong. At least you got to ruin my day, I hope that's a consolation prize for you. There is NO meaningful connection between the completion vs polling futures model and the epoll vs io-uring IO models. comex's comments regarding this fact are mostly accurate. The polling model that Rust chose is the only approach that has been able to achieve single allocation state machines in Rus…

To hopefully make your day better.

I for one, amongst many people I am sure, am deeply grateful for the work of you and your peers in getting this out!

Post reply on HN