HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
dotnet
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.

Languages & Compilers
Explore on GitHubRead Hacker News discussions
33Distinct people
45Mentions
1Explicit recommenders
1.6KGitHub stars
REPOSITORY AT A GLANCE

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

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.

Announcing .NET 11 direct repository linkDebated

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 8

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.

0510152020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 16 mentions; 4 submissions, 12 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 14 mentions; 2 submissions, 12 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments. Incomplete calendar period.2026*

* 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
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC808
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC16412
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC14212
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC202

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 GitHub

What Hacker News says

16 sources
withoutboats3·Oct 6, 2023
Just last month .NET ended a green threading experiment, mainly because the overhead it adds to FFI was too high: https://github.com/dotnet/runtimelab/issues/2398 Rust had green threads until late 2014, and they were removed because of their impact on performance. Everyone has done the basic research: green threading is a convenient abstraction that comes with certain performance trade offs. It doesn't work for the kind of profile that Rust is trying to target.
In Thread-per-core
bad_user·Sep 19, 2023
It's not the same thing. The TLDR is that it needs “function coloring” which isn't necessarily bad, types themselves are “colors”, the problem being what you're trying to accomplish. In an FP language, it's good to have functions that are marked with an IO context because there the issue is the management of side effects. OTOH, the differences between blocking and non-blocking functions is: (1) irrelevant if you're going to `await` on those non-blocking functions or (2) error-prone if you use those non-blocking functions without `await`. Kotlin's syntax for coroutines, for example, doesn't require `await`, as all calls are (semantically) blocking by default. We should need extra effort to execute things asynchronously. One issue with “function coloring” is that when a function changes its color, all downstream consumers have to change col
Read the rest
or too. This is actually useful when you're tracking side effects, but rather a burden when you're just tracking non-blocking code. To make matters worse, for side-effectful (void) functions, the compiler won't even warn you that the calls are now “fire and forget” instead of blocking, so refactorings are error-prone. In other words, .NET does function coloring for the wrong reasons and the `await` syntax is bad. Furthermore, .NET doesn't have a usable interruption model. Java's interruption model is error-prone, but it's more usable than that. This means that the “structured concurrency” paradigm can be implemented in Java, much like how it was implemented in Kotlin (currently in preview). PS: the .NET devs actually did an experiment with virtual threads. Here are their conclusions (TLDR virtual threads are nice, but they won't add virtual threads due to async/await being too established): https://github.com/dotnet/runtimelab/issues/2398
In JDK 21 Release Notes

Showing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.