The discussion is characterized by a split between praise for .NET 11's technical features and severe criticism of Microsoft's aggressive upgrade cycle, alongside a contentious debate comparing C#'s complexity against Go's simplicity. Participants disagree on whether the ecosystem's maturity justifies the migration burden and argue over specific language design choices like ConfigureAwait and generics.
306 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4 · Supporting reply 5 · Supporting reply 6 · Supporting reply 7 · Supporting reply 8dotnet
runtimelab
Languages & Compilers2020–2026
dotnet / runtimelab
runtimelab
This repo is for experimentation and exploring new ideas that may or may not make it into the main dotnet/runtime repo.
33Distinct people
45Mentions
1Explicit recommenders
1.6KGitHub stars
What to know before exploring
What it is
This repo is for experimentation and exploring new ideas that may or may not make it into the main dotnet/runtime repo.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
IEnumerable is to C#/.NET, what std::begin() and std::end() are to C++, and LINQ is to C#/.NET what <algorithm> is to C++. Both interfaces and libraries respectively are the…
delta_p_delta_x used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- dotnet/runtime · linked in 4 of the same discussions
- davidfowl/aspnetcorediagnosticscenarios · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
Mentions over time
HN mentions by year45 dated mentions
Observed mentions: 2020-11-05 13:09:27 UTC to 2026-10-26 21:55:41 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 16 | 4 | 12 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 14 | 2 | 12 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
.NET Runtime Lab
This repo is for experimentation and exploring new ideas that may or may not make it into the main dotnet/runtime repo. Encouraging .NET Runtime Experiments describes reasons that motivated creating this repository.
Active Experimental Projects
Currently, this repo contains the following experimental projects:
Utf8String - A new UTF-8 String data type in the runtime.
FreeBSD - Port of .NET runtime to FreeBSD
NativeAOT-LLVM - LLVM generation for Native AOT compilation (including Web Assembly)
NativeAOT-Mint - Mono interpreter ported to Native AOT for dynamic execution support
ManagedQuic - Fully managed implementation of QUIC protocol
LLHTTP - a set of flexible, lower-level HTTP APIs.
CompatibilityPackages - a set of packages which help satisfy binary dependencies of .NETFramework assemblies on .NET.
Hot-Cold Splitting - Support the hot-cold splitting optimization in crossgen2.
ManagedZLib - Fully managed implementation of DEFLATE algorithm and GZip/ZLib envelope formats.
SwiftBindings - Swift bindings for .NET.
CoreCLR Interpreter - An interpreter for CoreCLR.
ZeroGC - A standalone, allocate-only CoreCLR GC for measuring the maximum achievable allocation throughput of an application.
You can create your own experiment, learn more here!
Completed Projects
s390x - Port of .NET runtime (Mono) to the s390x architecture. The changes were upstreamed to dotnet/runtime.
DllImportGenerator - Roslyn Source Generator used for generating P/Invoke IL stubs.
NativeAOT - .NET runtime optimized for ahead of time compilation.
JsonCodeGen - Code generation for JSON.
AssemblyBuilder.Save() - Prototyping the implementation of AssemblyBuilder.Save() functionality.
Green Threads - Prototyping the implementation of green threads.
NativeAOT for Android - Prototyping the Native AOT for Android apps and Java interop layer.
Async - Move support for async state machine generation from the C# compiler to the runtime.
Filing issues
This repo should contain issues that are tied to the experiments hosted here.
For other issues, please use the following repos:
For .NET Runtime issues, file in the dotnet/runtime repo
For .NET SDK issues, file in the dotnet/sdk repo
For ASP.NET issues, file in the dotnet/aspnetcore repo.
Reporting security issues and security bugs
Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) secure@microsoft.com. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the Security TechCenter.
Also see info about related Microsoft .NET Core and ASP.NET Core Bug Bounty Program.
.NET Foundation
.NET Runtime is a .NET Foundation project.
This project has adopted the code of conduct defined by the Contributor Covenant to clarify expected behavior in our community. For more information, see the .NET Foundation Code of Conduct.
License
.NET (including the runtime repo) is licensed under the MIT license.
Read the full README on GitHubWhat Hacker News says
45 sourcesThere's an experiment to create an LLVM-based Native AOT tool chain. I sincerely hope they work on this properly, so that we can have a properly optimized AOT. But I'm not sure if it will end up with less quirks.
https://github.com/dotnet/runtimelab/tree/feature/NativeAOT-...
In C vs. C#: racing VLC's Gaussian blurIt 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 Asy
Read the rest
nc epic issue.
It actually looks like they have decided not to add virtual threads to .Net:
https://github.com/dotnet/runtimelab/issues/2398
In Data, objects, and how we're railroaded into poor design (2018)I am holding out hope for NativeAOT-LLVM https://github.com/dotnet/runtimelab/tree/feature/NativeAOT-...
In A 10x Faster TypeScript.NET's Task<T> + the state machine box for it emitted by Roslyn start at about 100B of heap-allocated memory, as of .NET 8/9.
The state machines generated for those by F# don't seem to be far behind either (I tested this before replying, F#'s asynchronous computations aka async { } appear to be much less efficient however so the guidance is to avoid them in favor of task { } and .NET's regular tasks).
Notably, BEAMs processes come with their own per-process GC each, which is going to add a lot of additional cost every time a new process is spawned. In a similar vein, Go's goroutines pre-allocate quite a bit of memory for their virtual stacks (60 KiB?).
.NET's tasks, as sibling comment mentions, are stackless coroutines[0] so their memory usage is going to be much lower. They come with a different set of tradeoffs but overall their cost is
Read the rest
going to be significantly cheaper because bytecode is JIT/AOT compiled to native, the GC has precise tracking of object liveness and because .NET does not perform BEAM-style preemptive userspace scheduling.
Instead, .NET employs work-stealing threadpool with hill-climbing thread count scaling to achieve optimal throughput. This way, when the workers cannot advance all submitted work items in time, additional threads are injected, which are then preempted by kernel thread scheduler. This means that even if other workers are busy, the work items will not wait in the queues indefinitely. This is a pathological case and usually the thread count varies between 1-2x physical core count.
This has a downside of achieving potentially worse scheduling fairness, and independent tasks allocating can and do affect each other w.r.t. GC pause impact. I believe this to be non-issue because this is more than compensated for by spending <10x CPU time vs BEAM on computing the same result, and significantly less memory (I don't have hard numbers but .NET is quite well behaved in terms of allocation traffic) too. At the end of the day, Task<T> is designed for much higher granularity of concurrency and parallelism so it would be quite unusable if it had greater cost.
If you're curious, I made an un-scientific and likely incorrect but maybe interesting comparison some time ago (it's in Ukrainian but the table is readable enough I hope):
https://gist.github.com/neon-sunset/8fcc31d6853ebcde3b45dc7a...
This calculates the CPU time and max MEM RSS usage required to spawn 1M tasks/coroutines/processes/futures that sleep for 5s and await their completion.
[0]: This might stop being true in a pure sense of the word in .NET 10 because the task handling is going to be completely changed by replacing state machines generated by a language that targets .NET with specially annotated methods, for which the runtime itself is going to implicitly emit state machines instead, allowing to pay the cost only at "true" suspend points. Reference: https://github.com/dotnet/runtimelab/blob/feature/async2-exp...
For everyone reading this blog post I caution to take the conclusions there with a grain of salt as they are an interpretation of the notes written down here: https://github.com/dotnet/runtimelab/blob/feature/async2-exp...
It is difficult to draw conclusions at the present moment on e.g. memory consumption until the work on this, which is underway, makes it into mainline runtime. It's important to understand that the experiment was first and foremost a research to look into modernizing async implementation, and was a massive success. Now once that is proven, the tuned and polished implementation will be made.
Once it is done and makes into a release (it could even be as early as .NET 10), then further review will be possible.
With that said, thank you for writing it, .NET tends to be criminally underrated and slept on by the most of the i
Read the rest
ndustry, and these help to alleviate it even if just a bit.
I don't know if this proposal makes a lot of sense.
The existing async1/TPL path is stable & predictable. If you find yourself needing more performance, you can reach for hardware Thread instances and use whatever locking/waiting/sharing/context strategies you desire. Anything else is a weird blend of compromises that is going to have caveats that are not immediately obvious for your specific use case.
For example, async2 w/ runtime JIT appears to have some tradeoffs with regard to GC & memory usage and the experiment writeup leaves some open-ended questions here[0].
[0]: https://github.com/dotnet/runtimelab/blob/feature/async2-exp...
In Async2 – The .NET Runtime Async experiment concludesThis FAQ is a bit outdated in places, and is not something most users should worry about in practice.
JVM Green Threads here serve predominantly back-end scenarios, where most of the items on the list are not of concern. This list also exists to address bad habits that carried over from before the tasks were introduced, many years ago.
In general, the perceived want of green threads is in part caused by misunderstanding of that one bad article about function coloring. And that one bad article about function coloring also does not talk about the way you do async in C#.
Async/await in C# in back-end is a very easy to work with model with explicit understanding where a method returns an operation that promises to complete in the future or not, and composing tasks[0] for easy (massive) concurrency is significantly more idiomatic than doing so
Read the rest
with green threads or completable futures that existed in Java before these. And as evidenced by adoption of green threads by large scale Java projects, turns out the failure modes share similarities except green threads end up violating way more expectations and the code author may not have any indication or explicit mechanism to address this, like using AsyncLocal.
Also one change to look for is "Runtime Handled Tasks" project in .NET that will replace Roslyn-generated state machine code with runtime-provided suspension mechanism which will only ever suspend at true suspension points where task's execution actually yields asynchronously. So far numbers show at least 5x decrease in overhead, which is massive and will bring performance of computation heavy async paths in line with sync ones:
https://github.com/dotnet/runtimelab/blob/feature/async2-exp...
Note that you were trivially able to have millions of scheduled tasks even before that as they are very lightweight.
[0]: e.g. sending requests in parallel is just this
using var http = new HttpClient() {
BaseAddress = new("https://news.ycombinator.com/news")
};
var requests = Enumerable
.Range(1, 4)
.Select(n => $"?p={n}")
.Select(http.GetStringAsync);
var pages = await Task.WhenAll(requests);
It's a different model. Microsoft did work on green threads a while ago and decided against continuing.
Links:
https://github.com/dotnet/runtimelab/issues/2398
https://github.com/dotnet/runtimelab/blob/feature/green-thre...
In Java Virtual Threads: A Case StudyAsync/await is not a tight corner as showcased by a multitude of languages adopting the pattern: Rust, Python, JavaScript and Swift. It is a clean abstraction where future progress is possible while retaining the convenience of its concurrency syntax and task composition.
Green threads experiment proved net negative in terms of benefit but the follow-up work on modernizing the implementation details of async/await itself was very successful:
Issue https://github.com/dotnet/runtime/issues/94620
Technical details https://github.com/dotnet/runtimelab/blob/feature/async2-exp...
The result is such that regardless of p/invoke existence green threads would have been a worse tradeoff.
It also seems that common practices in Java indicate that properties are not a mistake as showcased by popularity of Lombok and dozens of other libraries to generat
Read the rest
e builders and property-like methods (or, worse, Java developers having to write them by hand). In addition, properties existed in C# since its inception, that's...not a few years.
Not entirely sure about string interpolation but if you are alluding to `var text = $"Time: {DateTime.Now}";`, then it's a non-issue - APIs that care about it in complex contexts like querying a DB or logging can handle it with interpolated string handler API which allows to pass string interpolation expression to methods accepting interpolated string handler types, which can then, for example, generate parametrized query with sanitized inputs, without any friction for the user. Something that Java does not seem to sufficiently appreciate.
Example: https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...
We can't tailor every feature to the widely disparate preferences of so many developers nor do we try to convince every last developer of the merit of our approach -- this is both impractical and a losing strategy. Rather, we rely on our experience designing a highly successful language and platform, and consult with companies -- each employing thousands of Java developers -- and authors of some of the most popular relevant Java libraries to ensure that we meet their requirements. Of course, we also look at what other languages have done and the tradeoffs they've accepted (some of which may not be appropriate for Java [1]), but there are always many possible designs and we don't adopt one from a less successful language just because it, too, has its fans.
I would encourage those who think that we're consistently making suboptimal choices
Read the rest
for Java compared to choices made by significantly less successful languages to consider whether it is possible that their preferences are not aligned with those of the software market at large. Java is and aims to continue being the world's most popular language for serious server software, and that requires tailoring designs to a very large audience.
I always notice a certain lack of respect on forums such as HN for the world's most consistently successful and popular languages -- JS, Java, and Python. Different programmers have different preferences and I'm all for rooting for the underdog now and again, but you simply cannot consistently make wrong decisions over a very long period of time and yet consistently win. What we do may not be everyone's cup of tea (no language is), but it is clearly that of a whole lot of people. We work to offer value to them.
[1]: E.g. the design of native interop has significantly impacted that of user-mode threads (or lack thereof: https://github.com/dotnet/runtimelab/issues/2398) in both .NET and Go, and we weren't willing to make such tradeoffs in either performance or programming model.
Green Thread Experiment in .NET
2 points · Open discussionThere was a "green thread" experiment for dotnet a while ago, here is the conclusion: https://github.com/dotnet/runtimelab/issues/2398
In Is .NET just miles ahead or am I delusional?Initial experiment issue: https://github.com/dotnet/runtime/issues/94620
Experiment results write-up: https://github.com/dotnet/runtimelab/blob/e69dda51c7d796b812...
TLDR: The green threads experiment was a failure as it found (expected and obvious) issues that the Java applications are now getting to enjoy, joining their Go colleagues, while also requiring breaking changes and offering few advantages over existing model. It, however, gave inspiration to subsequent re-examination of current async/await implementation and whether it can be improved by moving state machine generation and execution away from IL completely to runtime. It was a massive success as evidenced by preliminary overhead estimations in the results.
In Why choose async/await over threads?Yeah, it kind of is. There are quite a few of experiments that are conducted to see if they show promise in the prototype form and then are taken further for proper integration if they do.
Unfortunately, object stack allocation was not one of them even though DOTNET_JitObjectStackAllocation configuration knob exists today, enabling it makes zero impact as it almost never kicks in. By the end of the experiment[0], it was concluded that before investing effort in this kind of feature becomes profitable given how a lot of C# code is written, there are many other lower hanging fruits.
To contrast this, in continuation to green threads experiment, a runtime handled tasks experiment[1] which moves async state machine handling from IL emitted by Roslyn to special-cased methods and then handling purely in runtime code has been a massive success a
Read the rest
nd is now being worked on to be integrated in one of the future version of .NET (hopefully 10?)
[0] https://github.com/dotnet/runtime/issues/11192
[1] https://github.com/dotnet/runtimelab/blob/feature/async2-exp...
Showing the 15 most recent of 45 sources. Enable JavaScript to search and browse every indexed mention.