Anders Hejlsberg

And then when my result is ready, then I can come back and continue executing here.

Well, in order to do that in

in an inverted architecture like that you have to build a state machine and state machines are notoriously hard for for people to implement because you've got to move all of your state off of the stack into objects you've got to remember where and then you have this big case statement that envelopes your entire logic and it's it's like it's a nightmare to to figure out right but the transformation from

serially executing code into a state machine, this continuation processing style translation, is actually one that you can do in a machine-based fashion.

You can have the compiler write the state machine if you introduce syntax that allows you to indicate where you want to yield.

And that's what await is.

Await is basically, I'm saying, I want to yield here, and then when, and I want

to yield this promise.

And then when the promise completes, I want you to come back here and continue executing.

And then the compiler writes a state machine around it.

And it actually turns it into this big switch statement, you know, and moves all of the state that survives across the await into something that's heap allocated so it can be brought back.

And doing all of that work is something that compilers are great at.

And so that was sort of the idea that

We have this new style of programming where we're using promises or the equivalent of promises and the ability to yield, and then we have callbacks.

But trying to write your program in that style, that's also what JavaScript suffers from a lot, right?

It's like all this...

callback style stuff.

And with async await, you get sort of the illusion that you're just writing normal sequential code.

And then the compiler does the painful transformation for you.

And that turns out to be really useful.