3 ms·
This doesn't go deep enough IMHO, I only really 'grokked' async/await (and how it differs from stack-switching coroutines) once I understood that it's just synt
by flohofwoe 3y ago
This doesn't go deep enough IMHO, I only really 'grokked' async/await (and how it differs from stack-switching coroutines) once I understood that it's just syntax sugar for a "switch-case state machine" (meaning you can emulate async/await-style in any language, even plain old C running on a heavily restricted VM like WASM).
For instance look at the JS output of async/await Typescript when a really old JS version is used that didn't support async/await yet.
It's switch-case all the way down:
https://www.typescriptlang.org/play?target=1#code/FAMwrgdgxgLglgewgAgO4EM4wBQEpkDewyyATgKYxikoTmrIAKpCAtnAM7nbYUcIAbAG7l8AXgB8hYiWRcYAFTityCMDjzJJ02bL6CR2AORKVamGXL9h5ACZHcAbhkkAvgBpkAJgAMfpzKuAa7AwOgcAJ7QyODQ8EjIrJgQmkQkUEjW5AB0AggA5sYAohAwpBEOzjIZEBwWfGACFmLI6BhYaJg4AemZgjl5hQ1NAdV9AgMFxQAeWJUyFFQ0yEYASpTUEEbOIUA https://www.typescriptlang.org/play?target=1#code/FAMwrgdgxg...
- capableweb 3y agoThere is more happening than switch-cases though, evident even from your link (it mentions Promises but doesn't provide the implementation for it). I think what another comment mentioned is more accurate: > Asnyc/await is just syntactic sugar for promises. > Promises are just wrappers around callbacks. > Callbacks are used to hook functions into an event loop. The dispatching/scheduling is handled there. > So really when you use async/await, you’re just writing pseudo-sequential code that gets turned into callback code. https://news.ycombinator.com/item?id=37360151 https://news.ycombinator.com/item?id=37360151
- bheadmaster 3y ago>> So really when you use async/await, you’re just writing pseudo-sequential code that gets turned into callback code. Small nitpick: I wouldn't call it "pseudosequential", personally. By that logic, C is pseudosequential, because when you call a system call, your process state gets saved in the scheduler, control gets passed to the kernel, then when kernel finishes, your process state is resumed. Not even getting started on branch prediction and similar CPU optimizations. What I mean is, as long as you have a kernel and scheduling, there's no such thing as a real (userspace) sequential program. We just call them sequential because their side effects correspond to a sequential model of execution. So if the side effects of an async/await program corresponds to that of a sequential model, it's a sequential program. But I get the value of using that word for an explanation of the implementation.