Anders Hejlsberg

Now, arguably, an alternative way of doing this is to use threads in the OS.

But the problem with threads is that they come with preemptiveness.

And the OS has the ability to preempt you at any point in time.

And that's not necessarily what you want.

And

And, and your UI, now you have to be multi-threaded in your UI and all sorts of other problems come along with it.

Plus threads are heavyweight.

And typically not well suited for lightweight tasks like, like you can do with async functions.

So there are pros and cons.

You know, like async await introduces this notion of function coloring, which is unfortunate, where you have two kinds of functions, async functions and regular functions.

And all the red functions can call the blue functions, but the blue functions can't call the red functions.

And so that means once you want, you know, a red function, now everything above it has to be red.

And so if you want from a sync function to call something async, well, then you've got to turn this function into an async function and its caller has to be et cetera, et cetera, right?

So that's unfortunate, and that's why some environments like Go, for example, has Go routines and green threads, which are really language-emulated, lightweight threads that kind of do what I'm talking about, but at a much lower cost.

But you avoid the function coloring.

So there is a bunch of different things.

But, you know, but for an environment that already exists like JavaScript or like C Sharp and the Windows event loop and whatever, this was the right solution.

I think it was sort of a confluence of a number of things that happened in the early 2000s, right?

First of all, the JavaScript platform, execution platform,

matured a lot.