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

Async and Await in Rust: a full proposal

boats.gitlab.io

Post reply on HN
Print view View original

71–80 of 196 posts

Re: Async and Await in Rust: a full proposal

#71

Post by gpderetta »

I'm somewhat disappointed that rust is going with async style stackless continuations. I'm a huge fan of stackfull coroutines/continuations as they are much more elegant and flexible. The downside is that they need a full stack, but I strongly believe (but can't prove) that rust has enough annotations and lifetime capabilities that it should be able to guarantee single frame allocation (or even no allocation for fully scoped coroutines, like many generator use cases) in every situation that the async model would.

There is an ongoing discussion in the C++ world between traditional C# style async, a more extreme non-type erased version (similar to the rust implemation I think but unsafe) and stackfull coroutines. Some (like me) hope that an hybrid solution might be possible.

Re: Async and Await in Rust: a full proposal

#72

Post by skybrian »

dom96 wrote: post #29
AndyKelley wrote: post #8

This is exciting. It allows programmers to model their problems in code that fully accounts for the parallelism. For comparison, here is async/await in Zig: https://ziglang.org/documentation/master/#Coroutines Zig decided to go the other way - when you async call a function, it does eagerly evaluate until the first suspend point. This is less overhead than immediately suspending, plus it removes the dependency of the…

It's exciting to see so many systems programming languages implement async/await. For a further comparison, Nim works in the same way as Zig when it comes to eager evaluation. Something that I'm particularly proud of when it comes to Nim's async/await implementation is that everything, right down to the macro which defines what `await` means, is implemented in the standard library. The compiler only implements the co…

As another comparison, Dart started out delaying execution of async functions and then switched to eager in Dart 2:

https://groups.google.com/forum/#!topic/flutter-dev/3R9qhjNG...

Re: Async and Await in Rust: a full proposal

#73

Post by imtringued »

weberc2 wrote: post #39
anko wrote: post #23

Earlier quoted context omitted.

Threading sucks. It's a situation where you have some external process (the operating system) deciding when different pieces of work should be woken up, with no way of feeding this back (so it just bases it on relatively naive schedulers). In practice, most of your threads are in one form of wait loop or another and you've just got polling both inside the threads and with the scheduler. Have a look at Erlang if you w…

To pick some nits and generally elaborate, Erlang's VM also has a scheduler; it's not the presence or lack of a scheduler, it's how efficient it is and what guarantees it allows the programmer to make about their system. For example, OS schedulers are typically pre-emptive, which means your OS thread can get interrupted anywhere. On the otherhand, Go's scheduler (I'm using Go because I'm more familiar with it than wi…

>only allows context switching at well-defined points in your program.

Erlang works the same way. The VM scheduler will only context switch on a function call. for or while loops don't exist in Erlang which means there is no risk of blocking the scheduler.

Re: Async and Await in Rust: a full proposal

#74

Post by shawn »

gpderetta wrote: post #71

I'm somewhat disappointed that rust is going with async style stackless continuations. I'm a huge fan of stackfull coroutines/continuations as they are much more elegant and flexible. The downside is that they need a full stack, but I strongly believe (but can't prove) that rust has enough annotations and lifetime capabilities that it should be able to guarantee single frame allocation (or even no allocation for full…

Undelimited continuations are memory sieves. Delimited continuations are better but a bit less useful.

Re: Async and Await in Rust: a full proposal

#75

Post by imtringued »

maxxxxx wrote: post #67
eikenberry wrote: post #16

Earlier quoted context omitted.

I'm curious as to why you think that matters? Async/Await are general purpose concurrent programming abstractions.

They are a real problem in desktop apps when you have to shut down the app gracefully. If you call an async function during shutdown you can't really tell when the async chain is done and you have nothing to wait for. Just dealt with that in a .NET app that uses a 3rd party SDK that heavily uses async/wait. I had to build a whole layer of state management to just handle shutdowns. Simple threading would have been muc…

That just sounds like the API wasn't designed to support async/await rather than an inherent limitation. Something like Promise.all [1] is all you need to wait for multiple promises if the API had a way to accept a promise instead of a synchronous callback.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Async and Await in Rust: a full proposal

#76

Post by nine_k »

gpderetta wrote: post #40
kbumsik wrote: post #24

As an embedded system dev, I'm wondering if these async features can be implemented on bare-metal (or without runtime)? Maybe I'm dumb and it might be a wild thought but it would be great if I could easily integrate async language features with hardware interrupts.

I'm not familiar with the way rust is going, but in general Async can be implemented purely a compile time by turning an async function into a set of functions tail calling each other or a switch statement. The stack frame need to go somewhere, but with allocator support this does not need to be exclusively handled by the runtime.

This is likely doable if no I/O is involved in the scheduling of coroutines. Usually it is.

Re: Async and Await in Rust: a full proposal

#77

Post by steveklabnik »

gpderetta wrote: post #71

I'm somewhat disappointed that rust is going with async style stackless continuations. I'm a huge fan of stackfull coroutines/continuations as they are much more elegant and flexible. The downside is that they need a full stack, but I strongly believe (but can't prove) that rust has enough annotations and lifetime capabilities that it should be able to guarantee single frame allocation (or even no allocation for full…

This is already true with “tasks”; the chain of futures has a known stack size when you submit it to the event loop. It allocates the “stack” for the entire thing at once. So while the primitive may not have them, it’s still sorta there. This is only possible because the individual generators are stackless; if they were stack full, each future would get a stack individually.

Re: Async and Await in Rust: a full proposal

#78

Post by steveklabnik »

gpderetta wrote: post #40
kbumsik wrote: post #24

As an embedded system dev, I'm wondering if these async features can be implemented on bare-metal (or without runtime)? Maybe I'm dumb and it might be a wild thought but it would be great if I could easily integrate async language features with hardware interrupts.

I'm not familiar with the way rust is going, but in general Async can be implemented purely a compile time by turning an async function into a set of functions tail calling each other or a switch statement. The stack frame need to go somewhere, but with allocator support this does not need to be exclusively handled by the runtime.

Async/await is basically sugar for generators and futures.

Re: Async and Await in Rust: a full proposal

#79

Post by timClicks »

sametmax wrote: post #41
he0001 wrote: post #32

Why does it have to be either one? Why not the possibility of choosing the implementation you want to solve the problem? A language where you could easily run whatever you want would have my vote. Not having it shoved down my throat (I’m looking at you JS). While it’s possible to build most of it yourself you should have the possibility to choose.

Be careful with this. I'm not saying you should not do it, but consider you'll have to design it very carefully. In python you can chose what event loop to hook to async/await, and hence we have gevent, qt, uvloop, twisted, asyncio, tornado, trio and curio as competing implementations. They are very difficult to mix, and their ecosystems are mostly isolated, dividing the man power to add features, fix bugs, provide s…

Concur.

Although perhaps the situation in Python could have been mitigated somewhat if a protocol was defined early that implementations could have adopted? Context managers, iterators and decorators all work nicely together, even across language boundaries via the extensions API.

Re: Async and Await in Rust: a full proposal

#80

Post by steveklabnik »

api wrote: post #70

How about lightweight threads, or are they there already? Going to Go with its LWT goroutines was awesome. Would never want to go back to async, which is really just a manual way of implementing LWT.

You can sort of think of tasks as green threads. It just really depends on exactly how you define your terms; this area has a ton of similar sounding terms that different people define differently.

The downside of Go’s approach is the overhead of calling into C; Rust can’t afford this. Go can. IMHO both languages are making the correct choices with regards to their constraints.

Post reply on HN