Comment by hackerqwe

9 hours ago

Clearly legacy heavy weight threads, virtual or not, are not superior. That’s why Swift, Rust and Typescript all chose async/await for concurrency.

5 comments

hackerqwe

Reply
kdps  8 hours ago

> Clearly legacy heavy weight threads, virtual or not, are not superior.

Associating virtual threads with "legacy heavy weight threads" is a fundamental misunderstanding

> That’s why Swift, Rust and Typescript all chose async/await for concurrency.

And Java chose to join Team Go/Erlang. At the end of the day, async/await is just syntactic sugar for futures/promises, which are essentially a way out of callback hell.

Besides, Rust and Typescript aren't good examples here: a green-thread scheduler (a runtime component) contradicts Rust's philosophy, while Typescript is inherently constrained by Javascript.

pjmlp  9 hours ago

Except one of the milestones for .NET 11 is to offer similar mechanisms for async/await.

  • biglyburrito  7 hours ago

    Link?

    • pjmlp  6 hours ago

      It starts with the experiment,

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

      Which ended with,

      > We have chosen to place the green threads experiment on hold and instead keep improving the existing (async/await) model for developing asynchronous code in .NET. This decision is primarily due to concerns about introducing a new programming model. We can likely provide more value to our users by improving the async model we already have. We will continue to monitor industry trends in this field.

      Now three years later we have,

      https://github.com/dotnet/core/blob/main/release-notes/11.0/...

      > Runtime async is a major runtime feature in .NET 11 that introduces new runtime-level infrastructure for async methods. The goal is to improve tooling and performance for async-heavy codepaths. For more details and to track progress, see the Runtime Async epic issue.