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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:05:26 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
8 sources> Can .NET deploy a static binary nowadays?
You can, as sbelskie mentioned below. In .Net 6, it's available as a Preview [1]. But it's going to ship with the main framework in 7.0 [2].
The preview works quite well. You can build self-contained, smaller executables, and shared libraries callable from say, C code.
[1]: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/...
[2]: https://github.com/dotnet/runtime/issues/61231
In .NET 6 ReleasedHow does a single metric from a highly specialized runtime environment indicate a tech stack is dead?
There are things you can do right now [1] to mitigate these cold start issues.
Going forward, ahead-of-time compilation will be an option. [2]
Aside from cold starts, note that the improvements in .NET make ASP.NET Core one of the fastest web frameworks. [3]
The article:
> “.Net has almost the same performance as Golang and Rust, but only after 1k iterations(after JIT).”
Additions like async/await and nullable reference types make it easier to write bug-free code, which for a lot of folks is a better trade off than “speaking to the hardware directly”.
.NET also runs natively on a bunch of platforms now, including ARM.
I’d call all of that continuous improvement. Perhaps even reinvention?
[1] https://docs.microsoft.com/en-us/dotnet/core/d
Read the rest
I think the short answer to your question is "no".
For single-file-no-project simplicity your best bet is dotnet-script: https://github.com/filipw/dotnet-script
For native code your best bet is NativeAOT: https://github.com/dotnet/runtimelab/tree/feature/NativeAOT
I'm not aware of anything that combines the two.
As to why: it's not so much that they've made it hard as they haven't made it easy. The reason they haven't made it easy is that it's a fringe use case. The main benefits of AOT are faster startup time, smaller storage requirements, and compliance with the iOS interpreted language ban. Most people who worry about those things don't mind having a project file.
They _have_ made some changes that may partly address your concerns. Visual Studio is no longer required to build C#; you can do it purely from the command line. There is als
Read the rest
o a new project file format. It's still XML, but much simpler. The HelloWorld example[0] from NativeAOT is a good example of how simple it can get. And the command line tools include an easy way of creating basic project files[1], so you don't have to memorize what little boilerplate remains.
[0] https://github.com/dotnet/runtimelab/tree/feature/NativeAOT/...
[1] https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-ne...
> AOT compilation? I'll believe it when they'll release it, until then, it's all speculation
Devil's in the details, but there -is- AOT compilation[0]. While it hasn't been released as an official product, it has been used for a few projects including a commercial game [1]. And yes, they're looking into the next steps to make it a 'released' thing.[2]
[0] - https://github.com/dotnet/corert/
[1] - https://github.com/dotnet/corert/issues/8233#issuecomment-65...
[2] - https://github.com/dotnet/runtimelab/tree/feature/NativeAOT
In A curated list of .NET performance resourcesWhat does AOT have to do with benchmarks that don't use AOT and report great performance?
Also you're dramatically overstating how mature AOT is for dotnet
https://github.com/dotnet/runtimelab/tree/feature/NativeAOT
>This repo is for experimentation and exploring new ideas that may or may not make it into the main dotnet/runtime repo.
In A curated list of .NET performance resources> the JIT needs warmup just like java
You can use ReadyToRun[0] to pre-JIT portions of the code for faster startup. Full AOT compilation is in the works too[1] albeit it's still experimental.
[0]: https://docs.microsoft.com/en-us/dotnet/core/deploying/ready...
[1]: https://github.com/dotnet/runtimelab/tree/feature/NativeAOT
In Why Discord is switching from Go to Rust (2020)CoreRT was an experiment and it's concluded. The learnings and components like RyuJIT have now been moved to the new project called NativeAOT which has high priority.
https://github.com/dotnet/runtimelab/tree/feature/NativeAOT
In My preferred .NET console stackMy understanding is the opposite; now that they're planning to merge Mono and CoreCLR, there is significantly more pressure on the .NET team to have a proper AOT solution.
"Early adopters can experiment with native AOT form factor" is a priority-zero (highest priority) epic for .NET 6: https://github.com/dotnet/runtimelab/issues/248
In My preferred .NET console stack