[troupo]

> The alternatives are callbacks

No. The alternative is lightweight/green threads and actors.

The thing with await is that it can be retrofitted onto existing languages and runtimes with relatively little effort. That is, it's significantly less effort than retrofitting an actual honest-to-god proper actor system a la Erlang.

[matheusmoreira]

> The alternative is lightweight/green threads and actors.

How lightweight should threads be to support high scale multitasking?

Writing my own language, capturing stack frames in continuations resulted in figures like 200-500 bytes. Grows with deeply nested code, of course, but surely this could be optimized...

https://www.erlang.org/docs/21/efficiency_guide/processes.ht...

This document says Erlang processes use 309 words which is in the same ballpark.

[troupo]

I didn't have to answer :) Thank you for looking it up.

Erlang also enjoys quite a lot of optimizations on the VM level. E.g. a task is parked/hybernated if there's no work for it to perform (e.g. it's waiting for a message), the switch between tasks is extremely lightweight, VM internals are re-entrant, employ CPU-cache-friendly data structures, garbage collection is both lightweight and per-thread/task etc.

[antihero]

Isn’t await often just sugar around the underlying implementation be that greenthreads, epoll, picoev, etc?

[troupo]

I think it depends on the language?

Javascript's async/await probably started as a sugar for callbacks (since JS is single-threaded). Many others definitely have that as sugar for whatever threading implementation they have. In C# it's sugar on top of the whole mechanism of structured concurrency.

But I'm mostly talking out of my ass here, since I don't know much about this topic, so everything above is hardly a step above speculation.

[lukaslalinsky]

> The alternative is lightweight/green threads and actors.

Those are all some form of coroutines.