> 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."
I meant my comment a bit more broadly & abstractly than that. You can write code in a new way with await, and it does help you with how to factor & manage the code. But it does not fundamentally let you make parallel requests that you couldn't make before, somehow. The code you needed before await might be ugly and stateful and not idiomatic, but it was still possible to make requests and wait for them, before await arrived.
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.
Okay, yeah, that is fair. I have written enough raw futures in anger to be like "it's not practically possible", but you're also right that it is actually practically possible, regardless.
Oh, practical is also separate from my answer, since my reading of the question was strictly "theoretical". ;)
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.
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."