Read the discussion on HN. A full-thread summary is not available yet.
dotnet
runtime
C#2019–2026
dotnet / runtime
runtime
.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
197Distinct people
337Mentions
1Explicit recommenders
18.4KGitHub stars
What to know before exploring
What it is
.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
GitHub
Where it is used
- Stack Overflow — Stack Overflow moved their service to .NET Core and saw lower page render times and improved latency. This reflects the site running on the .NET runtime after the migration. Source
What people are saying
> It is irrelevant that the benchmark is written in Oberon. It is not irrelevant from my perspective. It might be mostly irrelevant if Oberon, as you say, "fairly directly"…
rndgermandude 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/aspnetcore · linked in 5 of the same discussions
- webassembly/gc · linked in 5 of the same discussions
- dotnet/runtimelab · linked in 4 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, 12:45:45 PM UTC.
Mentions over time
HN mentions by year337 dated mentions
Observed mentions: 2019-12-06 14:10:04 UTC to 2026-09-21 15:39:47 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 |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 26 | 5 | 21 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 34 | 6 | 28 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 51 | 3 | 48 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 38 | 3 | 35 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 96 | 4 | 92 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 79 | 9 | 70 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 12 | 1 | 11 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
.NET Runtime
What is .NET?
How can I contribute?
Reporting security issues and security bugs
Filing issues
Useful Links
.NET Foundation
License
This repo contains the code to build the .NET runtime, libraries and shared host (dotnet) installers for
all supported platforms, as well as the sources to .NET runtime and libraries.
What is .NET?
Official Starting Page: https://dotnet.microsoft.com
How to use .NET (with VS, VS Code, command-line CLI)
Install official releases
Documentation (Get Started, Tutorials, Porting from .NET Framework, API reference, ...)
Deploying apps
Support (Releases, OS Versions, ...)
Roadmap
How can I contribute?
We welcome contributions! Many people all over the world have helped make this project better.
Contributing explains what kinds of contributions we welcome
Workflow Instructions explains how to build and test
Dogfooding .NET explains how to get nightly builds of the runtime and its libraries to test them in your own projects.
Reporting security issues and security bugs
Security issues and bugs should be reported privately to the Microsoft Security Response Center (MSRC) via the MSRC Researcher Portal. You should receive a response within 24 hours. Further information can be found in the Security TechCenter. You can also find these instructions in this repo's Security doc.
Also see info about related Microsoft .NET Bounty Program.
Filing issues
This repo should contain issues that are tied to the runtime, the class libraries and frameworks, the installation of the dotnet binary (sometimes known as the muxer) and the installation of the .NET runtime and libraries.
For other issues, please file them to their appropriate sibling repos. We have links to many of them on our new issue page.
Useful Links
.NET source index / .NET Framework source index
API Reference docs
.NET API Catalog (incl. APIs from daily builds and API usage info)
API docs writing guidelines - useful when writing /// comments
.NET Discord Server - a place to discuss the development of .NET and its ecosystem
.NET Foundation
.NET Runtime is a .NET Foundation project.
There are many .NET related projects on GitHub.
.NET home repo - links to 100s of .NET projects, from Microsoft and the community.
ASP.NET Core home - the best place to start learning about ASP.NET Core.
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.
General .NET OSS discussions: .NET Foundation Discussions
License
.NET (including the runtime repo) is licensed under the MIT license.
Read the full README on GitHubWhat Hacker News says
26 sourcesTheir new products aren't necessarily better in all ways, so beware before upgrading. True for most manufacturers. Some things I'm watching to gauge maturity of M1 Macs and Big Sur:
- DDC support is broken: https://github.com/MonitorControl/MonitorControl/issues/323
- Rosetta + debugger crashes: https://github.com/dotnet/runtime/issues/44958
- nmap crashes whole machine (!): https://github.com/nmap/nmap/issues/2193
- and of course the Homebrew compatibility table: https://github.com/Homebrew/brew/issues/7857
In Big Sur 11.1 External Display IssuesSupport .NET 5 on Apple Silicon with Rosetta 2 emulation
1 points · Open discussionThe C# libraries either invoke the native Linux libraries directly or go throw a thin wrapper[1] that does the normal things you have to do to support multiple flavors of Unix (epoll vs kqueue, etc). Parts of the C++ runtime are written in terms of the Win32 API and on Unix these API are implemented in the PAL[2]. The PAL is not that big and I don’t the steady state performance critical code paths go through it.
1: https://github.com/dotnet/runtime/tree/master/src/libraries/...
2: https://github.com/dotnet/runtime/tree/master/src/coreclr/sr...
In .NET 5.0I can’t speak for the original post, but I’ve seen other people[1] increase the commit count because part of the build process looks for a specific commit to checkout after cloning. If you have pull requests landing concurrently and you only clone the most recent commit, there is a race condition between when you queue the build with a specific commit id and when you start the clone.
All that being said, I don’t know why you would need you build agents to clone the whole damn repo for every build. Why not keep a copy around? That’s what TFS does.
One other thing I've seen to reduce the Git clone bottleneck is to clone from Git once, create a Git bundle from the clone, upload the bundle to cloud storage, and then have the subsequent steps use the bundle instead of cloning directly. See these two files for the .NET Runtime repo[2][3]. I ass
Read the rest
ume they do this because the clone step is slow or unreliable and then the subsequent moving around of the bundle is faster and more reliable. It also makes every node get the exact same clone (they build on macOS, Windows, and Linux).
Lastly, be careful with the depth option when cloning. It causes a higher CPU burden on the remote. You can see this in the console output when the remote says it is compressing objects. And if you subsequently do a normaly fetch after a shallow clone, you can cause the server to do ever more work[4].
1: https://github.com/dotnet/runtime/pull/35109
2: https://github.com/dotnet/runtime/blob/693c1f05188330e270b01...
3: https://github.com/dotnet/runtime/blob/693c1f05188330e270b01...
4: https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...
I caught a JIT bug in .NET back when I worked at Microsoft. Unfortunately I don't remember the specifics, but it was doing something wrong when trying to optimize a bit of code using AVX instructions.
I was immediately sure it was a compiler bug when I realized I could make the code work correctly if I changed the order of variable declarations. It would happen on something like:
int a;
int b;
float c;
(again, that's only illustrative - too long ago for me to remember the specifics)
But not with:
int a;
float c;
int b;
Folks in my team didn't want to believe it at first :)
Edit: found it here - https://github.com/dotnet/runtime/issues/17395
Not quite as I described but close.
In It Is Never a Compiler Bug Until It IsIf you read three, include Stephen Toub
Why?
>https://github.com/dotnet/runtime/graphs/contributors
In .NET Memory Performance AnalysisInteresting, they are removing WinRT support from .NET 5 CoreCLR and instead adding a system that lets the Windows team plug in the marshaling stuff:
https://github.com/dotnet/runtime/issues/35318
coreclr.dll is currently half a megabyte smaller than the 3.1 release.
In .NET Team Survey: Native AOTMicrosoft is working on ARM64 performance for .NET 5: https://github.com/dotnet/runtime/issues/35853
In Improving Performance of PHP for Arm64 and Impact on Amazon EC2 M6g InstancesYou'll find the detail in https://github.com/microsoft/openjdk-proposals/blob/master/s...
This is about stack allocation of objects where safe (i.e. when you can prove they don't escape the local scope) for Hotspot, something that already exists in J9 (IBM's JVM) I think.
There is equivalent work for .net core here: https://github.com/dotnet/runtime/blob/master/docs/design/co...
(So the title is somewhat accurate, but you have to do some digging)
In HotSpot compiler: Stack allocation prototype for C2> This document describes work to enable object stack allocation in .NET Core.
> In .NET instances of reference types are allocated on the garbage-collected heap.
> If the lifetime of an object is bounded by the lifetime of the allocating method, the allocation may be moved to the stack.
https://github.com/dotnet/runtime/blob/master/docs/design/co...
In HotSpot compiler: Stack allocation prototype for C2Improving Credit for Community Contributions
1 points · Open discussionIt was fixed.
https://github.com/dotnet/runtime/issues/8744
In Why Skylake CPUs Are Sometimes 50% Slower (2018)The change in .Net Core: https://github.com/dotnet/runtime/commit/03bf95c8db9003a5925...
(The implementation might be different on .Net Framework)
In Why Skylake CPUs Are Sometimes 50% Slower (2018)Showing the 15 most recent of 26 sources. Enable JavaScript to search and browse every indexed mention.