> More recently I'm still not sure why, in a language with an extensive runtime and its own VM, they went with async / await rather than fibers or continuations like go and java. It was probably simpler to implement initially, of course

Async/await work much much better than goroutines for GUI programs, which was still a major market at the time this feature was added to C#. Since there is a single GUI thread where everything that touches the GUI must live, but you do want your application to have multiple other threads, you need to give the programmer this kind of control and can't rely on a more simplistic Go-style green threads runtime.

I believe COM also has some similar requirements, but I am less sure than I am for GUI.

Finally, C# has a lot of influence from the functional langauge community, so it's possible that async/await and Task values were a more appealing solution given those particular tastes.

> Async/await work much much better than goroutines for GUI programs, which was still a major market at the time this feature was added to C#. Since there is a single GUI thread where everything that touches the GUI must live, but you do want your application to have multiple other threads, you need to give the programmer this kind of control and can't rely on a more simplistic Go-style green threads runtime.

Couldn't you have the GUI thread on one core, and the "goroutine pool" taking all the other cores, and distribute work on that pool? The model would be a bit more complex than Go, but considering C# is made for a wider variety of usages, multiple models wouldn't be so far fetched.

> Since there is a single GUI thread where everything that touches the GUI must live, but you do want your application to have multiple other threads, you need to give the programmer this kind of control and can't rely on a more simplistic Go-style green threads runtime.

Isn't that just a limitation of Go since its goroutines all run in the same pool? As far as I know, in the Java implementation you'll be able to create virtual thread pools from regular threads (i.e. the gui thread) and then have another virtual executor for the rest of your program. You'll still have the backend vs gui split but you won't have the entire async await split for the rest of your application.

I mean, technically, you don't have to have async/await in C#. Nothing's stopping you from using threads from the thread pool.

IIRC, they went with async/await because it could be implemented through desugaring in the compiler using a technique similar to what they had implemented a few months earlier with IEnumerable. That is to say, the team was thinking about desugaring at the time the need for asynchronous functions arose and they were not thinking about CSP. Remember that C# was in production at the time and they needed something that would not potentially upset the world.

> More recently I'm still not sure why, in a language with an extensive runtime and its own VM, they went with async / await rather than fibers or continuations like go and java. It was probably simpler to implement initially, of course.

No one was willing to approve another extension of the old runtime, and a major one at that. If they had already completed the .Net Core rewrite back then they would've probably baked async into the runtime.