https://javapro.io/2026/03/05/java-25-and-the-new-age-of-per...
https://docs.oracle.com/en/java/javase/26/core/virtual-threa...
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.
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.
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?