3 ms·

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

lenkite 4mo ago
We are not taking about legacy heavy weight OS/platform threads. But "green" threads managed by the language runtime like Go. Java went the Go/Erlang way. https://javapro.io/2026/03/05/java-25-and-the-new-age-of-performance-virtual-threads-and-beyond/ https://javapro.io/2026/03/05/java-25-and-the-new-age-of-per... https://docs.oracle.com/en/java/javase/26/core/virtual-threads.html https://docs.oracle.com/en/java/javase/26/core/virtual-threa...
pjmlp 4mo ago
Except one of the milestones for .NET 11 is to offer similar mechanisms for async/await.
- biglyburrito 4mo ago
  Link?
  - pjmlp 4mo ago
    It starts with the experiment, https://github.com/dotnet/runtimelab/issues/2398 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/preview/preview1/runtime.md#runtime-async 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.
    - biglyburrito 4mo ago
      Awesome, thank you! So it's going to be an internal implementation change -- that is, it generates the MSIL code that's generate when a developer writes async/await code, and won't require changes to how a developer writes async/await code?
kdps 4mo 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.

lenkite 4mo ago

We are not taking about legacy heavy weight OS/platform threads. But "green" threads managed by the language runtime like Go. Java went the Go/Erlang way. https://javapro.io/2026/03/05/java-25-and-the-new-age-of-performance-virtual-threads-and-beyond/ https://javapro.io/2026/03/05/java-25-and-the-new-age-of-per... https://docs.oracle.com/en/java/javase/26/core/virtual-threads.html https://docs.oracle.com/en/java/javase/26/core/virtual-threa...

pjmlp 4mo ago

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

biglyburrito 4mo ago
Link?
- pjmlp 4mo ago
  It starts with the experiment, https://github.com/dotnet/runtimelab/issues/2398 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/preview/preview1/runtime.md#runtime-async 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.
  - biglyburrito 4mo ago
    Awesome, thank you! So it's going to be an internal implementation change -- that is, it generates the MSIL code that's generate when a developer writes async/await code, and won't require changes to how a developer writes async/await code?

kdps 4mo 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.