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

11–20 of 196 posts

Re: Async and Await in Rust: a full proposal

#11

Post by yazaddaruvala »

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 seems like the next logical step. A language where all functions are async/await.

And it’ll likely pull in some nice features from academia like, building a dependency graph of async statements so it can automatically reorder async statements to get optimal concurrency.

Re: Async and Await in Rust: a full proposal

#12

Post by noobermin »

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.

Not everything is a webserver/frontend/web related.

Re: Async and Await in Rust: a full proposal

#13

Post by jononor »

majewsky wrote: post #2

Usually we add notes like (2016) to old articles. In this case it would be appropriate to add (April 2018) to the title given how fast the futures ecosystem is moving in Rust.

If there is an even newer resource that is better, just link it here in a comment?

Re: Async and Await in Rust: a full proposal

#14

Post by noobermin »

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.

I feel like you're making a very interesting point but it seems a bit broad and abstract for me to justify in my head. Could you clarify what you mean?

Re: Async and Await in Rust: a full proposal

#15

Post by barrkel »

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.

That model is called green threads.

Continuation passing style means passing along your continuation to your callee, and is the implementation of the async model. But normal calls do pass their continuation: the return address, pushed on the stack, is the continuation function, and the stack itself is the scope, and together they are a closure. Make the stack a first class value that can be switched, and you get to continuations - and that's what the runtime gets with green threads.

It means much harder interop because you can't have native frames on your stack. But you have the same problem with async.

Re: Async and Await in Rust: a full proposal

#16

Post by eikenberry »

noobermin wrote: post #12
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.

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.

Re: Async and Await in Rust: a full proposal

#17

Post by arianvanp »

yazaddaruvala wrote: post #11
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 seems like the next logical step. A language where all functions are async/await. And it’ll likely pull in some nice features from academia like, building a dependency graph of async statements so it can automatically reorder async statements to get optimal concurrency.

This is Haskell's IO type and its do notation !

And the reordering of statements exists too. It's called ApplicativeDo[0] and is heavily used at Facebook[1]

[0] https://www.microsoft.com/en-us/research/wp-content/uploads/...

[1] https://youtu.be/sT6VJkkhy0o

Re: Async and Await in Rust: a full proposal

#18

Post by ori_b »

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.

Concurrency has overhead. On top of that, synchronous is easier to reason about.

Re: Async and Await in Rust: a full proposal

#19

Post by ploxiln »

noobermin wrote: post #14
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.

I feel like you're making a very interesting point but it seems a bit broad and abstract for me to justify in my head. Could you clarify what you mean?

If you want easier concurrency with higher overhead, that's exactly what OS threads do. The OS kernel is the "event loop" in this case, and they're highly optimized for this, though there is some overhead which is hard to avoid.

Rust has gone back and forth on this. Pre-1.0 versions of Rust had a "green threads" mode. It was removed in favor of OS threads because it wasn't worth the complexity.

Go is a language in which "all functions are async" and it's pretty cool. But it needs a runtime, and interop with C / C++ has some real overhead related to switching to a C-style stack. Rust did not want to make those compromises, it wanted to be appropriate for bare-metal or kernel programming, and for libraries used by big high-performance C++ applications. In these cases, Go's model does not work well.

I personally use Go a lot, it's great for network services and command-line tools, and that's mostly what I do.

Re: Async and Await in Rust: a full proposal

#20

Post by Koshkin »

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.

> a function needs to await something

According to a famous quote, the source of which escapes me, "await does not wait for anything, and async is not asynchronous." (This could be specific to C# though.)

Post reply on HN