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.

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."

What we have now with await does change the game, it makes async code appear synchronous, and the advantages of that change should not be underestimated. I think futures & await are huge and positive changes for every language they're showing up in, and they do allow for new kinds of programming, I'm just answering the parent comment's question about whether they're strictly necessary in theory. The answer is that they're not.

Maybe about a decade ago I wrote a raw futures system for async asset loading off DVDs on the Nintendo Wii in C++, and it had to play nice with the real-time rendering system. I didn't stand back far enough to abstract it the way futures work today, and as a result it was an absolutely awful experience. It was so difficult to understand and debug, I dug myself an enormous hole. Having used futures in JavaScript and Scala and other languages since, I'm certain having real futures would have saved me months of crunching.

I would agree that await syntax brings a huge degree of practicality to what was previously theoretically possible.

And yeah, that's sort of how it works under the covers :)

  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
    }
  }

For gather, I think the problem w/ your proposed

  return alpha + beta + gamma

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

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

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.

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)
    }

    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)
    }

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

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

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

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

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.