Why asynchronous Rust doesn't work

Post by winter_squirrel » Wed, Mar 10, 2021, 12:43 PM UTC

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.

Post by Diggsey » Wed, Mar 10, 2021, 12:46 PM UTC

pas wrote: post #237

zamalek wrote: post #193

Earlier quoted context omitted.

> A bigger problem in my opinion is that Rust has chosen to follow the poll-based model This is an inaccurate simplification that, admittedly, their own literature has perpetuated. Rust uses informed polling: the resource can wake the scheduler at any time and tell it to poll. When this occurs it is virtually identical to completion-based async (sans some small implementation details). What informed polling brings to…

Could you explain what is informed and stateless informed polling? I haven't really found anything on the web. Thanks!

Post by reasonabl_human » Wed, Mar 10, 2021, 12:48 PM UTC

saurik wrote: post #183

newpavlov wrote: post #87

Earlier quoted context omitted.

It's certainly possible to pave over the difference between models to a certain extent, but the resulting solution will not be zero-cost. Yes, there is a fundamental difference between those models (otherwise we would not have two separate models). In a poll-based model interactions between task and runtime look roughly like this: - task to runtime: I want to read data on this file descriptor. - runtime: FD is ready,…

FWIW, I'd bet almost anything that this problem isn't solvable in any general way without linear types, at which point I bet it would be a somewhat easy modification to what Rust has already implemented. (Most of my development for a long time now has been in C++ using co_await with I/O completion and essentially all of the issues I run into--including the things analogous to "async Drop", which I would argue is actu…

Post by roca » Wed, Mar 10, 2021, 12:52 PM UTC

thu2111 wrote: post #223

xiphias2 wrote: post #36

Earlier quoted context omitted.

That’s why it’s amazing, type safe efficient multi-threading without dynamic memory allocation with a nice syntax...it’s the holy grail of server programming.

Why would I want to write a server in a language that requires such awkward approaches to basics like coroutines and dynamic dispatch when I could use kotlin on the JVM and get pauseless GC, ultra fast edit/compile/run cycles, efficient and powerful coroutines, and eventually Loom which will eliminate the whole problem of coloured functions completely and let me just forget about coroutines? Multi threading bugs are…

Post by zokier » Wed, Mar 10, 2021, 12:53 PM UTC

noncoml wrote: post #156

eminence32 wrote: post #21

> Was spinning up a bunch of OS threads not an acceptable solution for the majority of situations? It's worth remembering that this is still a very acceptable thing to do in some cases. And spawning OS threads is sometimes easier to write and easier to read, and easier to reason about than async code. Just because async is in the language, don't feel like you need to use it everywhere.

> 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