They did that after the learnings with experiment of having a Erlang, Go, Java like implementation for async, await.

Is this a joke, like "hen's teeth"? Those languages don't have async/await.

No joke at all, not that I said "like implementation", not that they have async/await.

https://github.com/dotnet/runtimelab/issues/2398

Be sure to read all the way to the bottom,

They don't need to mark functions as needing special compilation / rewriting to support asynchronous use since the runtime provides the necessary mechanism to pause and resume (e.g. stackful continuations). So 'async' is unnecessary and 'await' can be a library function (or remain a keyword of course).

Seems to be a gift of the modern CLR cycling faster with each release since .NET 5 versus the backwards compatibilities the runtime used to have to keep in .NET <= 4 because the same runtime would power multiple versions at a time of the compilers and BCL above it. In the old world "Framework" days after the CLR made the huge changes from 1.0 to 2.0 (for generics and other things) it seemed almost "afraid" to add features, especially for things that compilers could support themselves. The .NET 5+ CLR makes fewer "forward compatibility" guarantees as it now assumes it cycles directly with the compilers and that most deployment methods "bake" the CLR version with the application.

There have been smaller runtime improvements like this one in recent releases, but this one seems a big one to point to to prove that the runtime is truly growing at a faster and more interesting pace than the old days.

Friendlier stack traces have an important upside: Cancellation is done by throwing exceptions, but you can't stop it from storing the full stack trace in a string. This can result in a noticeable hitch if the stack is very deep and complex. With a friendlier stack trace, I hope this issue is finally gone.

As the article mentions, stack traces in exceptions are the one place where this change doesn't really move the needle: they were already hiding stack frames related to the async machinery in exception stack traces. The main benefit here is the live call stack in the debugger.

> One especially useful result is a clearer live call stack. Profilers and debuggers can show the asynchronous methods themselves instead of the infrastructure used to execute them. This is a distinction from exception stack traces, which already hide much of that infrastructure.

i have been seeing a lot better performance, to be honest. It allocates a LOT less.