Update on await syntax in Rust

https://boats.gitlab.io/blog/post/await-decision-ii/

by steveklabnik • 7 years ago

275 189 7 years ago

boats.gitlab.io

CJefferson• 7 years ago

I'm nit going to stop using rust, but I find this very disappointing.

One thing I strongly disagree with - - this article said other notations would require Rust users having to learn more notation. This still requires learning more notation, just it's easy to not even be aware it exists and think a struct had a member called await instead...

Pahr3yah• 7 years ago

Await is a keyword, syntax highlighters will most likely paint it differently.

kbenson7• 7 years ago

I find the syntax highlighting argument odd. It's like arguing a road surface is acceptable because the dangerous conditions it causes are mitigated by traction control.

JoshTriplett• 7 years ago

Speaking as a member of the Rust language team: we specifically evaluated all syntax proposals on the assumption that many people may end up reading them without syntax highlighting. People read code in many places outside of a programmer's text editor or a code-highlighting web page, including logs, diffs, and emails.

kbenson7• 7 years ago

My understanding of the issue (which is shallow at best) is that it's a battle between a prefixing keyword or sigil which has the problem of causing the reader to scan back and forth in the statement when chaining multiple items, which sucks), or a postfixing keyword or sigil, with dot notation for a keyword to help parsing (and everyone seems to dislike the overloading of the dot notation for this). Ignoring sigils, I think the chosen solution is the lesser of two evils.

That said, I think a postfixing sigil would have been much better. It seems an important enough thing to denote that a bit of special syntax is called for, and the more unique the better.

0815test• 7 years ago

That said, I think a postfixing sigil would he been much better. It seems an important enough thing to denote that a bit of special syntax is called for

They can still introduce a sigil later, if the .await syntax turns out to be common enough in code that the long keyword hinders readability. This is how it was done with the try!(...) feature, which now uses ? as a sigil. But as the article points out, pure sigils are a scarce resource so .await might well be the best way to go anyway.

Nican• 7 years ago

For example, on C#, I sometimes have to do:

  var value = (await (await startRequest()).GetBody()).Root;

While the Rust syntax would make this a little more clear, I do not think it is a dealbreaker.

burke• 7 years ago

Yeah this argument doesn't hold water for me either. Learning new notation versus learning a special-cased exception to the normal semantics of an existing piece of notation feel like really comparable levels of cognitive overhead to me.

I don't think this is necessarily a bad choice overall but I find this particular line of reasoning a bit specious.

numakerg3• 7 years ago

Why couldn't they use a macro or a function?

EDIT: nvm. it says in TFA not the linked writeup

steveklabnik20• 7 years ago

It cannot exist as a macro or function, because it transforms the code in ways they can’t. Macros can transform code, but the final output isn’t something representable in stable Rust, and so it would not compile post-expansion.

amelius• 7 years ago

It's not just learning the new notation. It's also that you probably can't override it with your own implementation (useful perhaps in embedded environments).

kibwen9• 7 years ago

I don't see why you'd need to override await, because unlike in other languages Rust doesn't implicitly insert machinery for facilitating task execution. You need to provide your own task executor, which is the part that embedded environments would want to (and will be able to) have control over.

hn_throwaway_99• 7 years ago

I come from the Node world (I'm not really familiar with Rust at all), where the syntax is "await foo()", and to be honest I really like the .await syntax. First, as others have stated it makes the operator precedence clearer in my opinion. But more importantly, in my brain it makes it feel like await is a "member operator" of Promises (or I guess futures in the Rust case), so I can think "Function returns a promise, and then "calling" await on it yields and then returns the resolved object when done".

BozeWolf• 7 years ago

Nice! That was quicker then I Expected. How far are they with the implementation? Not using rust, but following progress because it is on hackernews so much.

Why does it take so long for swift to have this? Swift + iOS developers really really benefit from it. And there are loads of ios developers compared to rust developers.

Arnavion• 7 years ago

It has been usable on nightly since `nightly-2019-05-09` (with https://github.com/rust-lang/rust/pull/60586 )

tracker14• 7 years ago

There seems to have been a lot of groundwork for the Futures specification as well as implementations of underlying features for a while.

Not too dissimilar for JavaScript's async/await syntax which needed support for Promises and Generators as progress points.

Analemma_• 7 years ago

The fact that discussions over syntax generate pages and pages of furious bickering, while discussions over semantics (which is what actually matters) get a shrug, is the ultimate example of bikeshedding in PL design. Honestly, syntax just doesn't matter. Yes, particular poor choices can impede usability, but that's not applicable here, and ultimately after two minutes or so of learning the new syntax there's no difference between this and "await foo".

arkitaip• 7 years ago

This is every topic on Hacker News so I'm not sure why anyone would be surprised or really care.

anchpop3• 7 years ago

Syntax may be irrelevant at the end of the day, but nice syntax can make a big difference in usability imo. I'm not following the Rust example, but discussions of it remind me about discussions about UFCS (Universal Function Call Syntax). That's where `foo(a, b)` can be rewritten as `a.foo(b)`. That may seem minor, but look at this code:

    half_square = divide(square(a), 2)

In comparison to:

    half_square = a.square().divide(2)

Many find the latter much more pleasant to read, and things like this can make a big difference in how fun I find it to use a language.

Retra2• 7 years ago

What's a big difference for you got to do with the design of a language used by many others? What makes your experience more important than the experiences of someone with different qualifications?

Why is optimizing for your tastes the correct thing to optimize for?

byproxy• 7 years ago

Interesting example...I find the first much easier to read and reason about. ¯\_(ツ)_/¯

sagichmal4• 7 years ago

Whatever pleasantness may come from that or any other specific example is totally outweighed by the constant overhead of having to remember that there are N ways to do 1 thing. As a primary rule: the best programming grammar has the fewest such ambiguities, ideally zero.

_v7gu• 7 years ago

I think you can skip the empty () in D. The syntax becomes much more readable when you don't have to return to upper levels of functions. Thankfully pipes exist in functional languages, which makes it feel just right

    half_square =
      a
      |> square
      |> divide(_, 2)

cle• 7 years ago

They both matter. Confusing syntax can lead to just as many bugs as confusing semantics.

(I'm not arguing that they weren't bikeshedding...)

aerovistae• 7 years ago

I would say syntax is everything. What's the difference between python and Haskell without syntax?

hyperion2010• 7 years ago

Lazy vs strict semantics are completely orthogonal to the syntax [0]. (foo a b c) looks the same in a lazy language as it does in a strict language but oh boy are the results surprisingly different if you don't already know what you're in for.

0. Though some would argue that making them completely orthogonal to the point where the user can't tell the difference is a horrible design decision.

axelf4• 7 years ago

While I do have an opinion on the syntax I could never amass the time necessary to weigh the positives/negatives of semantics issues. I reckon that's the reality for many.

swsieber• 7 years ago

Oh. There was lots of discussion over semantics, with people who worked on implementing (e.g. language creators) await/async in other languages. The problem/solution space was a lot smaller though.

Also, there is a notable usability difference, wrt reading the flow of lines, chaining and parentheses. Learnabilty/wierdness was a syntax consideration, but not the only one.

steveklabnik20• 7 years ago

It's also worth noting that the semantics were settled a long time ago. Syntax was the only thing left to actually discuss.

kibwen9• 7 years ago

while discussions over semantics (which is what actually matters) get a shrug, is the ultimate example of bikeshedding in PL design

Worth noting that in this case the discussion over semantics has been ongoing and nonstop since around 2013, since it's such a big feature that it took a lot of trial and experimentation to figure out, and only then after being broken up into several large sub-tasks which all had to be individually discussed as well; see the epic comment thread on the Pin stabilization tracking issue as an example of just one semantic discussion towards this end: https://github.com/rust-lang/rust/issues/49150

staticassertion9• 7 years ago

If syntax didn't matter we wouldn't see conformity to a set few styles, with outliers having a far more difficult time gaining traction.

Syntax very obviously matters.

Besides, futures are very old in Rust at this point (relative to the language's age) and had been discussed years ago. The reason people aren't seeing those discussions is because they happened a long time ago but syntax happened a month ago.

nathcd2• 7 years ago

Indeed. I'm reminded of http://www.paulgraham.com/identity.html. I think it's just easy to have an opinion on syntax.

I think this also highlights the pitfalls of being community-centric. If Rust were run more like chromium or something, this sort of thing just ceases to be an issue. Major kudos to the Rust team for managing it really well.

majewsky• 7 years ago

There was not just disagreement within the community, but also within the language team. Any other language is going to have the same problem at times (except for those that are a one-man show). The only difference is that you see how the sausage gets made. (Also, electronic communication is less efficient than in-person.)

rileywatkins• 7 years ago

What a milestone! This was the most impressive work in open source decision-making that I have ever followed (in my limited experience). People have contributed thousands of comments discussing this for over a year. It has even caused the team to rethink how discussions like this should be guided in the future beyond comments on GitHub issues. I cannot imagine how difficult it has been to manage it all, and I applaud and thank the Rust team for their hard work in fielding comments, weighing trade-offs, and ultimately making a decision in order to move the project forward.

hu3• 7 years ago

This was the most impressive work in open source decision-making that I have ever followed...

You'd be blown away by Linux Kernel development then. Multiple magnitudes above any measurement of an await syntax bikeshedding. /u/Perceptes puts it best than I ever could in this top voted comment on /r/rust [1]:

"...I personally don't care at all about the await syntax, and have been very unhappy with that bikeshed being such a focus of time and discussion. The real problems I have with the unstable async system are how difficult it is to reason about. Compiler errors are still largely indecipherable. impl Trait didn't really help here. Documentation is still sparse, so I spend a lot of time banging my head against the wall, trying many formulations of my programs to get just the right incantation of futures wrapped in futures wrapped in futures to get things to compile, only to get page-long type mismatch errors that are near impossible to read, and multiple closures/functions deep of nested futures being returned where any of them could be the culprit. I'm also very frustrated by the lack of progress on "abstract types" that are required for using async functions (and returning impl Trait) from trait methods. Traits are the cornerstone of Rust's type system and yet I haven't seen any activity on this for months. And now we're talking stabilization with this glaring hole. Async streams are another thing I've seen almost no progress on, aside from a blog post from withoutboats on how to deal with the ? operator within async for loops..."

This was 2 months ago, mind you. [1] https://www.reddit.com/r/rust/comments/awa3t1/baby_steps_blo...

I'm just glad that they finally settled on something.

yingw7873• 7 years ago

I'm not familiar around the syntax, but I'm interested to know how much of this was a religious battle and how much of it results in meaningful complications for user code down the line. I've heard really good things about the Rust community (like nothing bad at all), until maybe two weeks ago when somebody mentioned this stuff. I'm a really big fan of not having religious battles.

Is this syntax for native coroutines? Can it be combined with existing user and stdlib syntax? What pathways for syntax development does this decision cut off entirely, and pathways does it leave open? What did the Rust community / maintainers learn from this debate, and how can the Rust community avoid such battles in the future?

steveklabnik20• 7 years ago

I'm interested to know how much of this was a religious battle and how much of it results in meaningful complications for user code down the line.

Due to the connotations of "religious battle", it's hard to get a good answer here. Nobody wants to be painted in this light.

Is this syntax for native coroutines?

No.

Can it be combined with existing user and stdlib syntax?

Yes.

What pathways for syntax development does this decision cut off entirely, and pathways does it leave open?

Nothing outside of the async/await feature itself.

What did the Rust community / maintainers learn from this debate, and how can the Rust community avoid such battles in the future?

This is too long for an HN comment :)

ben5095• 7 years ago

Due to the connotations of "religious battle", it's hard to get a good answer here. Nobody wants to be painted in this light.

Haven't we all found ourselves lined up as one of a pair of camps over some heated dispute over a bit of minutiae? The whole time you know it's a bit silly, but not entirely and you feel compelled to continue to argue.

Using a term like "religious battles" with tongue firmly in cheek is recognizing that we're prone to such things because we're human beings, by putting a lampshade on it.

yingw7873• 7 years ago

@steveklabnik My apologies if I appeared to make light of the Rust community’s contributions. My definition of religious war is butting heads about problems that don’t have a clear right answer (tabs/spaces). If there are new things considered by the community that make the discussion worthwhile then it’s absolutely worth having; but if it causes people to burn out on the community down the line then maybe more moderation would be helpful. I have no experience leading anything like Rust, but I talked to contributors who burned out on Python and various libraries and it’s sad to see, so ideally Rust would forge a better path.

My impression of async/await is that it’s one part of making concurrency grokkable, and I’m not sure whether the debate was taking all that into account: https://vorpus.org/blog/some-thoughts-on-asynchronous-api-de...

seanalltogether• 7 years ago

Question for people more familiar with async/await semantics, how do you typically control what thread the async procedure runs on? Having spent a lot of time now in rxJava and really getting into the power of stream processing and composition, it feels like async/await is almost too simplistic.

sagichmal4• 7 years ago

You typically don't, as knowing which physical thread you're running in is (thankfully) becoming a relic of the past.

ridiculous_fish• 7 years ago

UI programming is one domain where it's important to know this.

imtringued• 7 years ago

Java parallel streams use a global thread pool by default. The problem with this is that if you mix IO bound code and CPU bound code in the same thread pool the IO bound code will block the CPU bound code. If you don't explicitly choose the thread pool your code runs on then you will suffer from impossible to debug performance problems.

steveklabnik20• 7 years ago

async/await produces a Future. In order for that Future to execute, you place it on an executor. It won't start executing until you do so. Which thread it runs on, and how, is all the executor's job. So the answer is basically "pick the executor which has the semantics you want".

hinkley• 7 years ago

I never liked this behavior in Java. Or rather, I wasn't sure it was right or wrong and then I found code where people returned a future without starting it, causing the caller to wait forever in some situations.

Also if you use multiple modules with their own executors, they don't compose well. You can easily get oversubscription of CPUs.

Javascript's promises are self starting, which I would say is an improvement but the total lack of back pressure is anywhere from galling to highly problematic depending on the problem domain.

Goldilocks solution might be to have default executor behavior with an obvious and straightforward way to override it.

kbsletten• 7 years ago

In C#, your tasks are submitted to the ambient task scheduler. In ASP.NET, this is (I believe) the main thread pool that handles requests. The only time I've ever had to care where something was running is when adding response headers because that's available as a thread local API that can't happen on another thread, but it's generally ended up as a "it hurts when I do this" kind of situation.

tracker14• 7 years ago

In C#/ASP.Net use Context.Items or otherwise create your own context to track what you need.

deskamess• 7 years ago

ConfigureAwait(false) may help if you want it to run "not in the current context". Has UI/library use cases [1].

https://medium.com/bynder-tech/c-why-you-should-use-configur...

Const-me• 7 years ago

In C#, this is defined by the current thread's synchronization context.

If you're writing a console application, the main thread doesn't have one. When an async function wants to resume, it will usually resume on some thread pool's thread. Potentially different one each time. Can be any other thread too, the runtime just resumes running the function on the same thread which completed the await.

But if you're writing a GUI app and launching an async function from its GUI thread, that thread has a current sync.context. When the function will want to resume running or fails, the runtime will resume/raise exception on the same thread where it started. More precisely, the runtime delegates the decision to the sync.context, and the contexts set by GUI frameworks choose to resume on the GUI thread.

This may cause some funny deadlock bugs, but in most cases works surprisingly well in practice.

Also it's easy to implement custom synchronization contexts if needed.

WorldMaker• 7 years ago

Depends on the language and the circumstance.

In .NET it defaults to scheduling continuations in the "main" thread as much as possible, with the easiest escape valve being Task<T>.ConfigureAwait(false) that tells it that it can finish continuations wherever they land in the ThreadPool. This is why you can often find a lot of (partly mistaken) advice in .NET to always use ConfigureAwait(false) for "performance" which as often as not leads to people rediscovering the hard way why the easy default is continuations on Main/UI threads. There actually is a more complex TaskScheduler mechanism underlying that big ugly valve, but TaskScheduler is not quite as featureful or easy to control as the RX-equivalent scheduler.

(I heard some rumblings that the .NET team was considering in the long run to better unify async/await TaskScheduler scheduling with the Scheduler model of RX.NET, but I don't know if anything has progressed yet along those lines.)

Python mostly requires manual management of event loops for async/await coroutine scheduling. Most Python code, even/especially using async/await is still generally single-threaded (due to artifacts like the GIL [Global Interpreter Lock] that are getting better with each passing version of Python), so more complicated scheduling is both generally not necessary and also left as an exercise to the user.

ECMAScript 2017 (JavaScript) async/await is also mostly running in single threaded event loops (though not manually managed like Python; generally browser UI event loop managed).

apo• 7 years ago

The article doesn't actually show what the new syntax looks like. Nor does the article linked in the first paragraph.

What's a simple example of the new syntax?

thsowers• 7 years ago

expression.await

nailer• 7 years ago

Can you show us an example of, eg, an HTTP request?

chucksmash• 7 years ago

Postfixed and preceded by a dot is my understanding:

    pub async fn do_stuff() {
        // ...
    }

    // elsewhere, inside a fn
    // as svnpenn points out
    let result = do_stuff().await;

svnpenn• 7 years ago

await goes inside the function, at least thats how its done with JavaScript - do you have evidence otherwise?

https://developer.mozilla.org/Web/JavaScript/Reference/Opera...

nathcd2• 7 years ago

Awesome, thanks Rust team! I'm super excited for this to be stabilized.

That won’t be the end of the async/await feature - there will be a lot of extensions left out of the minimum feature

Is there a summary of these somewhere for perusal?

uryga2• 7 years ago

i saw https://areweasyncyet.rs/ linked here, it mentions future extensions

childintime• 7 years ago

All control flow mechanisms except await have their own statement: if, for, while, match. Howcome await is different?

The dot await syntax might hide an await within an expression, as "just another method". You'll need to hunt it down.

I feel await has costs and consequences that need to be explicit. The dot syntax does the opposite, and therefore I feel Rust might be making a mistake of a lifetime (pun intended) on this one.

kibwen9• 7 years ago

All control flow mechanisms except await have their own statement: if, for, while, match. Howcome await is different? The dot await syntax might hide an await within an expression, as "just another method". You'll need to hunt it down.

Not quite; Rust is an expression-favoring language, so `if`, `match`, and even the `loop` keyword can all appear deep within expressions (the first two do so somewhat commonly; the latter is comparatively rare). In addition, the error-handling operator `?` is also used within expressions. (And while we're on the topic, let's remember that even C, a statement-heavy language, also has `?` as a control-flow operator that is not in statement position.)

NyashMyash• 7 years ago

This guy is so qt and nice.

Thaxll• 7 years ago

I'm not familiar with Rust, someone can explains why they went with .await? Is await a field / method on a class / struct?

eximius10• 7 years ago

None of the above. It's compiler magic. It's a keyword that says 'await on this awaitable object' (currently only a Future can be await-ed).

You can read the OP which contains links to more blog posts on the reasoning. I think this is a bad decision precisely because of the questions you're asking. At least making it a 'magic method' (i.e., Future::await(...) or future.await()) with no implementation would have been better in basically every way. A 'dot' operator already exists and this just makes it confusing.

asark2• 7 years ago

I've been planning to try out Rust for a side project, and this decision is so principle-of-most-surprise that it's got me reconsidering, wondering what other unpleasant weirdness lurks in the language. Looking down their other options in one of the linked articles, they seem to reject a couple fine ones outright and then went with one I'd have rejected outright as being too hostile to anyone who's not quite familiar with the manual, having memorized exceptions to ordinary behavior like this. I'm struggling to understand why anyone liked this one at all, let alone enough to push it to the top of the pile.

Macha• 7 years ago

Why not JS/C#/Python style `await foo()` is discussed here:

https://paper.dropbox.com/doc/Await-Syntax-Write-Up-t9NlOSeI...

Main points against:

1. Interacts poorly with the ? operator for propagating errors. You'd need to do (await foo())?

2. Chains poorly. `await foo().bar().baz()`

- a. What are you awaiting? foo() or foo().bar().baz()

- b. What if you wanted to await foo().bar()? (await foo().bar()).baz() is messy.

- c. What if you wanted to chain promises? Like httpRequest.send().body() . In many libraries such as Python's requests, the first returns a future for a response with headers and only a later call waits until the body is returned. `await (await httpRequest.send()).body()`

Why not .await() or .await!():

https://boats.gitlab.io/blog/post/await-decision/

tracker14• 7 years ago

Time to update https://areweasyncyet.rs/ again...

Really looking forward to this once it reaches down into some of the network/web frameworks, database drivers etc.

eximius10• 7 years ago

Excited for the feature.

Disappointed we didn't get something like a magic method (e.g., lang item) (which isn't without precedence [1] [2]) so we could have had `Future::await(fut)` or `fut.await()`.

[1] https://manishearth.github.io/blog/2017/01/10/rust-tidbits-b... [2] - https://manishearth.github.io/blog/2017/01/11/rust-tidbits-w...

eridius9• 7 years ago

`fut.await()` looks too magical. There's no hint in that expression that it's anything other than a method call. You could argue the same about `fut.await`, except in this case `await` is a keyword and thus the expression `x.await` is known to be an await expression without knowing anything about `x`, whereas `fut.await()` requires knowing the type of `fut` to understand that the method call `.await()` resolves to the lang item. Also, since it's a lang item, you could write your own nostd library that picks a different name for the same lang item and cause even more confusion.

eximius10• 7 years ago

There's no hint in that expression that it's anything other than a method call.

Compared with `fut.await`...

There's no hint in that expression that it's anything other than a field access.

At least there is precedence for functions to have magical compiler-ness for 'doing stuff', instead of overloading field access which is one of the simplest operations you can have.

... requires knowing the type of `fut` ...

tbh, you don't need to know how await works. It goes and does stuff and returns a value. If you need to know what it does, you're looking up the types and seeing, 'oh its a future' and looking at that.

Contrast with the field access one and you don't even know its something else entirely.

I guess I just don't buy that it can't be a method. Like, formally, yea, it isn't a well-defined, safe Rust method. But make the impl

    fn await(self: Self) -> Self::Target {
        intrinsic::await(self)
    }

Now its a method defined on the `Future` trait, it's discoverable, it's clearly magic, it's ergonomic... In my opinion, it beats the field access one in every conceivable metric.

It's just frustrating, I guess.

Rusky4• 7 years ago

If we're gonna have await share syntax with some other language feature, method syntax is IMO better than field syntax- it semantically blocks the function until the callee is complete, it evaluates to a temporary instead of an lvalue, it can unwind the caller (via cancelation, like a panic).

You could implement that syntax and still make `await` a keyword, without doing the usual method lookup and without letting no_std libraries change the term, just like `.await`- that's an orthogonal concern.

ben5095• 7 years ago

A bit off-topic: Is there any theoretical reason you need async / await syntax at all?

(It's certainly desirable for performance and compatibility to avoid making all subroutines into coroutines, so I understand why most languages have done this.)

And restricting it to the case where coroutines have a single return...

Subroutines are naturally coroutines that don't yield. And it seems like the question of whether it's a subroutine or a coroutine shouldn't be something the programmer needs to worry about.

What I've seen in coroutine libraries is the main reason we need await seems to be for cases when we don't want to await a result.

If you need an unawaited invocation to pass to a routine like gather, you do this:

    my_results = await gather(run_job(x) for x in work)

But, even if we can't infer from the type of gather that it must accept a future, a function can have a method that asks it to return a future:

    my_results = gather(run_job.future(x) for x in work)

You'd often want to dispense with gather. If I have these statements:

    alpha = run_alpha()
    beta = run_beta()
    gamma = run_gamma()
    return alpha + beta + gamma

In most cases, e.g. if these were requests going over the network, we'd prefer to schedule all three at once. If we want to sequence side-effects, then explicit await makes sense:

    alpha = run_alpha.await()
    beta = run_beta.await()
    gamma = run_gamma.await()
    return alpha + beta + gamma

That makes the most concurrent option easiest, as opposed to the clunky idiom of "gathering" many results.

steveklabnik20• 7 years ago

In an abstract sense, no. In rust, it matters a lot. The first reason is that we don’t have a runtime. The second is stuff like http://aturon.github.io/2018/04/24/async-borrowing/

ben5095• 7 years ago

Thanks for the link, I'm definitely interested in how it's done without a runtime. I know in theory a coroutine can compile down to a gory switch statement and some state, but doing anything useful with it gets hairy, I'm sure.

deathanatos• 7 years ago

I think (but I cannot find a reference to now) one of the proposed syntaxes was that awaits were immediate and implicit in async functions, and that if you didn't want that, you could opt-out and get futures normally. Loosely,

  async fn foo() {
    let result = blocking_req();  // awaiting immediately here.
    async {
      let future = blocking_req();  // not awaited.
      // can do more complex stuff w/ the future
    }
  }

IDK what happened to it, and it is a bit more complex IMO than what the Rust folks went with. However, I don't think it helps your gather case.

For gather, I think the problem w/ your proposed

  return alpha + beta + gamma

is when does that happen? If I do

  let some = alpha + beta;
  // < ... code ... >
  let more = some + gamma;

what happens / when are things evaluated?

At any rate, with the syntax as it is, I think your gather example is essentially¹:

  alpha.join3(beta, gamma).await

  Future::join3(alpha, beta, gamma).await

(Perhaps minus the `.await`, depending on when you need/want the result.)

There's no operator overloading, which I'm fine w/, as there is a need to choose between, e.g., select or join.

¹but I'm new w/ the async stuff, so if I'm wrong I'm assuming that Cunningham's Law will kick in and someone will correct me.

Rusky4• 7 years ago

Here's the proposal: https://internals.rust-lang.org/t/explicit-future-constructi...

One of the goals behind it was to align async control flow with sync/thread-based control flow, to make it more intuitively obvious when things would run concurrently and when they would not. That is, calling a function, even if async, would immediately run it to completion, while wrapping it up in a closure or async block that gets spawned would run it concurrently.

This is especially relevant to Rust, which departs from other implementations of async/await in that merely constructing a future is insufficient to start it running, which is why you need that `join3` call to explicitly introduce concurrency.

Under the "implicit await" proposal, your first example would look like this:

    async fn foo() {
        let result = blocking_req(); // await immediately
        let future = async { blocking_req() }; // think of async{} like a lambda function
        // can do more complex stuff with the future, like:
        //  future.await()
        //  Future::join(future, other_future)
        //  tokio::spawn(future)
    }

The thread-based equivalent looks very similar:

    fn foo() {
        let result = blocking_req(); // block the current thread immediately
        let closure = || { blocking_req() }; // don't run this yet
        // can do more complex stuff with the closure, like:
        //  closure()
        //  rayon::join(closure, other_closure)
        //  thread::spawn(closure)
    }

ben5095• 7 years ago

The async block syntax would be nice, and probably far more explicit.

I think with the `return alpha + beta + gamma` the idea is that within a scope, everything is done as late as possible, but you can't leave a scope without all results.

Thus, if the code is expanded as:

    alpha = run_a()
    beta = run_b()
    gamma = run_c()
    a_plus_b = plus(alpha, beta)
    sum = plus(a_plus_b, gamma)
    return sum

In that case, the compiler has to determine a partial ordering:

    a_plus_b <- run_a, run_b
    sum <- a_plus_b, run_c

Thus it can generate:

    await gather(run_a, run_b, run_c)
    await plus(alpha, beta)
    await plus(a_plus_b, gamma)

And presumably you can detect pure subroutine / primitive invocations.

And there would be other hard points where tasks must be fully awaited; e.g. loops wouldn't be able to leak tasks.

kibwen9• 7 years ago

Indeed, I think going forward we will see high-level languages that paper over the distinction between synchronous and asynchronous functions. However for Rust specifically, the performance implications you note are of particular concern, while the remark "it seems like the question of whether it's a subroutine or a coroutine shouldn't be something the programmer needs to worry about" is debatable when considering languages that aim to sit at the same level of the stack as C.

ben5095• 7 years ago

I should revise that: "programmers aren't very good at deciding whether a function should be a subroutine or coroutine."

Specifically, the problem is that making the decision happen requires refactoring and that can make a small change into a big one. My contention is that for some languages (probably not Rust) it would be beneficial if this didn't impact the code structure heavily.

I've seen smart people simply avoid trying to use asynchronous code in Javascript because it "poisons" the whole stack. Part of this was because it was based on promises, and it meant going through a bunch of logic and refactoring. Arguing against my case, that did result in a slightly nicer structure overall.

Hopefully having proper async / await notation avoids 99% of that mess in Rust by making it a matter of decorating code with the appropriate keywords and being a bit more thoughtful about structure.

And you're obviously right that Rust needs to have sane performance characteristics, let alone being able to export C compatible bindings.

dahart3• 7 years ago

Is there any theoretical reason you need async / await syntax at all? [...] That makes the most concurrent option easiest, as opposed to the clunky idiom of "gathering" many results.

Futures / async-await is an idiom that makes async code easier to reason about, not something that provides any new theoretical foundation or any functionality that wasn't possible before. Like a type system, it's strictly for safety & convenience.

Whether & where you wait on any individual async request is largely separate from the await syntax. If you can start 3 async requests in parallel, and await on the group rather than each request, you probably should.

That said, the idiom of gathering results sequentially is guaranteed to work and be safe, where hidden dependencies and hard to identify race conditions have plagued attempts to make parallel async code since the beginning of time. The syntax of futures in various languages is making async and parallel code easier and safer for most programmers to use without landing in quicksand.

steveklabnik20• 7 years ago

Futures / async-await is an idiom that makes async code easier to reason about, not something that provides any new theoretical foundation or any functionality that wasn't possible before.

So, this is true in GC'd languages, but if you see my link below, in Rust, async/await does let you write code that was previously impossible. This is because the compiler can't understand lifetimes in the way that the code is written with raw futures.

In theory, someday, if and when generators are stabilized, this will be true again, but instead with the caveat of "async/await doesn't give you any new thing that wasn't possible before, except that it can do it with safe code, rather than unsafe code."

kgraves• 7 years ago

Fantastic! I'm extremely excited with this update on the Rust async/await syntax! I have been following the blog posts and the issue tracker for a long time and couldn't wait till this day arrived!

Eagerly waiting for the 1.37 release!

Great job Rust Team!

wst_• 7 years ago

I am amazed how well documented and transparent was the whole process. They new the decision would be difficult to make and there will always be people who wouldn't like the final syntax so they made sure to state their reasoning and trade offs clearly. Fantastic job. Can't wait for August. Thanks!

Dowwie• 7 years ago

I think that the majority of people still don't understand what they're not getting in August. It's an async-await mvp.

Update on await syntax in Rust

Related Stories