Rust

async is stackless coroutines, less powerful than stackful ones and vastly less powerful than first-class continuations, which is what call/cc provides, but also way more performant as there's basically zero memory management overhead....

Where do the call stacks for the different async tasks live and how are they allocated?

That's the neat thing: They aren't, futures don't contain their stack the compiler infers, statically, what they will need, and put that in a struct. As said, practically zero memory overhead.

First-class continuations aren't evil they're naughty, dirty only if used when not actually making anything clearer. Delimited continuations are actually a generalisation of call/cc and arguably way easier to think about, it's just that call/cc predates their discovery and made it into standard lisp and scheme, where is that Felleisen paper, here: 1988. 13 years after scheme, 28 after lisp. longjmp/setjmp exist since at least System V and C89 according to the linux man pages, I guess they implemented it to implement lisp in. It's just that C is about the worst language to use when you're writing anything involving continuations, everything gets very complicated very fast, and not because continuations are involved but because you have no gc, no nothing, to support you.

Rust lacks them, but so far that seems to me to be a shortcoming in Rust

I think it's a benefit. In Rust, you have two options:

• panic - usually catchable with catch_unwind() (some types are not), and should be used rarely, this isn't try/catch
• result - return a value that indicates an error, like a super fancy errno, but with monad semantics that force you to acknowledge it

This is good for a few reasons:

• "normal" errors are explicit in the return type; if a function doesn't return a result, it can't return errors
• outliers aren't accidentally handled - since you shouldn't be catching panics, you can rely on them to completely crash
• no need to instrument the code with unwinding logic in case something throws an exception, meaning a more efficient runtime

Where do the call stacks for the different async tasks live and how are they allocated?

The async runtime handles that. You'd need to look at the specific implementation to see how they handle it, the standard library only provides tools for dealing with async.

My understanding is that it works kind of like a generator, so any await call yields to the runtime, which resumes another generator. That's an over simplification, but hopefully it's close enough.

Call/cc

I think this is basically just the general idea of a generator, but the caller chooses where the yield yields to.

I agree with the criticisms of call/cc, and I think it's much clearer to just use coroutines (of which generators are a special case) and otherwise linear control flow instead of messing about with continuations. IMO, the only people that should mess with continuations are lower level engineers, like driver authors, compiler devs, and async lib devs. Regular devs will just create more problems for themselves.