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

61–70 of 196 posts

Re: Async and Await in Rust: a full proposal

#61

Post by gpderetta »

anko wrote: post #23
quotemstr wrote: post #9

Earlier quoted context omitted.

Having made "async" the default, you've just returned to regular threading, which is what we should have stuck with all along. The thread model is actually pretty useful, the pitfalls are well understood, and the tooling very mature.

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…

You can have userspace threads (or even hybrids m:n threading). They went out of fashion in the last decade for many reasons but were fairly common in the past.

Re: Async and Await in Rust: a full proposal

#62

Post by k__ »

TekMol wrote: post #5

I'm waiting for the day when 'async' will be the default function type and 'await' will be the default type of function call. If anywhere down the callstack a function needs to await something it has to become an async function. And this needs to be done to the whole callstack recursively. So over time more and more functions of every codebase turn into async functions.

So we remove async/await from our async functions and add sync/block to our sync functions? :D

Re: Async and Await in Rust: a full proposal

#63

Post by avodonosov »

pron wrote: post #28
TekMol wrote: post #5

I'm waiting for the day when 'async' will be the default function type and 'await' will be the default type of function call. If anywhere down the callstack a function needs to await something it has to become an async function. And this needs to be done to the whole callstack recursively. So over time more and more functions of every codebase turn into async functions.

This is the situation in Scheme, Erlang and Go (although the latter two strongly bind continuations with a specific, built-in scheduling), and what we're doing in Java as part of Project Loom. All Java functions will be able to run inside delimited continuations without modification. Continuations/coroutines are thus a purely dynamic rather than a syntactic entity.

Any news on Project Loom? When to expect it available?

Re: Async and Await in Rust: a full proposal

#64

Post by gpderetta »

quotemstr wrote: post #9
TekMol wrote: post #5

I'm waiting for the day when 'async' will be the default function type and 'await' will be the default type of function call. If anywhere down the callstack a function needs to await something it has to become an async function. And this needs to be done to the whole callstack recursively. So over time more and more functions of every codebase turn into async functions.

Having made "async" the default, you've just returned to regular threading, which is what we should have stuck with all along. The thread model is actually pretty useful, the pitfalls are well understood, and the tooling very mature.

FWIW, Scheme (among others) has async by default on steroids (aka call/cc) and is nothing like regular threading.

You can build threading on top of it but also all kind of other abstractions.

Re: Async and Await in Rust: a full proposal

#66

Post by infogulch »

TekMol wrote: post #5

I'm waiting for the day when 'async' will be the default function type and 'await' will be the default type of function call. If anywhere down the callstack a function needs to await something it has to become an async function. And this needs to be done to the whole callstack recursively. So over time more and more functions of every codebase turn into async functions.

I think it should be possible to design an async system that is generically async, i.e. whether a given function with no special annotations or syntax is async (including all of the async-able calls that function makes transitively) is entirely determined by the top-level caller at compile time. The called function doesn't need any special syntax, and in fact doesn't even need to consider being async at all: the async-capability bubbles up based on what other async-able functions it calls. Only the very ends of the chain: at the bottom doing IO via system calls, or at the very top where request handlers are first dispatched (for example) should need to think about being asynchronous or synchronous at all; everything in-between is compiled for whatever the top wants.

Re: Async and Await in Rust: a full proposal

#67

Post by maxxxxx »

eikenberry wrote: post #16
noobermin wrote: post #12

Earlier quoted context omitted.

Not everything is a webserver/frontend/web related.

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 much easier.

It's different with server side code. There async/await is very nice.

Re: Async and Await in Rust: a full proposal

#69

Post by dom96 »

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…

> Can you clarify what youre referring to with "decided to implement it in the compiler instead"

I'm referring specifically to the async/await syntax. Coroutines probably need to be implemented in the compiler, sure, but the actual async/await can be implemented with metaprogramming.

Post reply on HN