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

51–60 of 196 posts

Re: Async and Await in Rust: a full proposal

#51

Post by steveklabnik »

alexnewman wrote: post #31
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.

Pretty sure you need at least an operating system and memory allocation

Futures have landed in libcore, and do not inherently allocate.

You can write an executor with a fixed-size queue as well, and not require dynamic allocation at all.

Being able to do this is a hard constraint on the design.

Re: Async and Await in Rust: a full proposal

#52

Post by steveklabnik »

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…

Async blocks require a keyword to be unambiguous with a struct constructor.

Re: Async and Await in Rust: a full proposal

#53

Post by bluejekyll »

steveklabnik wrote: post #50
bluejekyll wrote: post #49

Earlier quoted context omitted.

What’s the TLS stuff to be sorted out?

IIRC, the initial implementation of async/await requires TLS. Eventually it won’t.

Oh! For some reason I jumped to Transport Layer Security, not Thread Local Storage... duh.

Yeah the Pinning stuff is supposed to help with this as I understand.

Re: Async and Await in Rust: a full proposal

#54

Post by aidanhs »

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…

Can you clarify what youre referring to with "decided to implement it in the compiler instead", be it from this blog post or elsewhere?

Clearly you need coroutines in the compiler, and the way Rust treats ownership means pinning is needed in some way (I've not been following closely so don't know if this is in libstd or a language-level feature), but the rest (according to this post) seems to be going in libstd so you can write your own if you want.

Re: Async and Await in Rust: a full proposal

#55

Post by Matthias247 »

UncleEntity wrote: post #21
nercury wrote: post #6

I want to reflect on that this is still done without any garbage collector.

Why would anyone assume that a GC is needed for async/await? The Future object seems to do the all bookkeeping needed by the borrow checker (which I believe is what rust uses to track the lifetime of objects).

Maybe because most future implementations (e.g. in Javascript, the proposed C++ solution, Seastar, etc) work by scheduling a continuation on an event loop. Which obviously requires at least some form of dynamic memory for queuing up these continuations.

Re: Async and Await in Rust: a full proposal

#56

Post by steveklabnik »

bluejekyll wrote: post #53
steveklabnik wrote: post #50

Earlier quoted context omitted.

IIRC, the initial implementation of async/await requires TLS. Eventually it won’t.

Oh! For some reason I jumped to Transport Layer Security, not Thread Local Storage... duh. Yeah the Pinning stuff is supposed to help with this as I understand.

Ah! Super reasonable, yeah. It can be confusing.

Re: Async and Await in Rust: a full proposal

#57

Post by drb91 »

gpderetta wrote: post #42
drb91 wrote: post #7

Earlier quoted context omitted.

Async being a “default” function type doesn’t make much sense unless you’re doing io. If you’re just computing, you often can’t proceed without the result and want to proceed as soon as you have the result—i.e. blocking. Both are critical to getting good performance. I’m curious if discerning which is the best type is possible to tool automatically with static or tracing analysis.

Generators, a-la python for example, are completely equivalent to async functions and have nothing to do with IO.

True! However, I believe rust has a separate, distinct yield/generator functionality coming that should address those needs separately. I think off-hand it’d be pretty easy to wrap them in a stream, or to join a stream into a generator, if you did want to compose them.

Re: Async and Await in Rust: a full proposal

#58

Post by anko »

millstone wrote: post #37
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…

Why would kernel threads be polling in practice? Won't most be waiting on locks, file descriptors, timers, etc?

You're right, in theory, if your select() or epoll() doesn't have a timeout. And the threads aren't doing any active work. But if you're optimising for that state, then you don't care about inefficiencies of one model or another.

There are also costs in setting and checking those locks etc. Sure, you can build solutions to optimise a broken model, which we've done over decades (with quite a bit of success!), but it doesn't make the model less broken.

Re: Async and Await in Rust: a full proposal

#59

Post by steveklabnik »

aidanhs wrote: post #54
dom96 wrote: post #29

Earlier quoted context omitted.

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…

Can you clarify what youre referring to with "decided to implement it in the compiler instead", be it from this blog post or elsewhere? Clearly you need coroutines in the compiler, and the way Rust treats ownership means pinning is needed in some way (I've not been following closely so don't know if this is in libstd or a language-level feature), but the rest (according to this post) seems to be going in libstd so yo…

Pinning is almost entirely a library feature; it does use the unstable “auto traits” functionality of the language, so it’s a bit special in that regard. But it’s provided by the standard library.

Re: Async and Await in Rust: a full proposal

#60

Post by steveklabnik »

drb91 wrote: post #57
gpderetta wrote: post #42

Earlier quoted context omitted.

Generators, a-la python for example, are completely equivalent to async functions and have nothing to do with IO.

True! However, I believe rust has a separate, distinct yield/generator functionality coming that should address those needs separately. I think off-hand it’d be pretty easy to wrap them in a stream, or to join a stream into a generator, if you did want to compose them.

That’s correct; async/await uses Generators under the hood, but we haven’t stabilized them yet. It’s the plan to though!
Post reply on HN