[anonymoushn]

You could use an actual stack. As I understand it this was not done for questionable reasons relating to borrows of thread-locals. You could also allocate a top-level async function and all of its transitive async callees all at once, if you force the user to put all this information in 1 translation unit. Or you could use a bump allocator specifically for futures used in a certain part of the program, if you're willing to give up using a global allocator for everything. So it seems like there are a lot of options.

[ComputerGuru]

All this is fine and dandy for async web apps but would make things like async-as-state-machine, which powers a lot of rust embedded development, basically a non-starter.

[anonymoushn]

In embedded development it's impossible to use any allocation strategy other than the language constantly calling a global malloc on your behalf?

[ComputerGuru]

Normal async doesn’t require any malloc.

[anonymoushn]

Great! I certainly didn't intend to say that stack-allocated or statically-allocated futures should somehow stop working?

[pcwalton]

If you're allocating a call stack per thread you might as well just use actual threads.

[anonymoushn]

This obviously doesn't work. Maybe you can try refactoring a console emulator that uses its stack switching primitive millions of times per second to use threads instead and let us know how well it runs.

[littlestymaar]

But you lose the async/await syntax (which I'm addicted to because it makes blocking point explicit, like `?` makes error explicit).