3 ms·

Java Virtual Threads are a superior paradigm to C#'s async/await and function coloring.

• hackerqwe 5mo 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.
  • lenkite 5mo 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 5mo ago
    Except one of the milestones for .NET 11 is to offer similar mechanisms for async/await.
    • biglyburrito 5mo ago
      Link?
      • pjmlp 5mo 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 5mo 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 5mo 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.
• youre-wrong3 5mo ago
  Hahahha no. lol just no.
• mrsmrtss 5mo ago
  I don't get what the big problem is with function coloring. You basically only need async when doing IO, and you had better know when a function does it, or you may have a bad surprise at some point in the future.
  • oaiey 5mo ago
    That! Okay, in 2026 this could be a LSP feature with some editor fanciness but this is a real benefit. My nitpick is that we do not have a depreciation on the non async ones
  • nchie 5mo ago
    Agreed, async function coloring makes for better structured code because it incentivizes keeping IO code near the edges while having a synchronous core.
• OneWingedShark 5mo ago
  Both are, IMO, inferior to Ada's TASK construct.