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
34 sourcesNOTE: this is just my perspective from observing the language evolve.
Anders Hejlsberg specifically mentions the "dynamic"[1] keyword. Normally C# is statically typed, that is at compile time you know the type of everything. With the "dynamic" keyword, function calls and field access are resolved at run time. For example if you have the following code:
dynamic myObj = new object();
Console.WriteLine(myObj.MyProp);
It will compile fine. At runtime it will crash, because System.Object has no property "MyProp". But if the object did have the "MyProp" property, it would have run fine. This example shows how dynamic can take C# from a statically typed language like Java and turn it into a dynamically type language like Python. From a language design perspective, this is a bit of an aberration from the statically typed path C# has take
Read the rest
n most of the time.
From a language implementation perspective, this feature has a high cost. It requires re-implementing features of the C# compiler as a library in the Microsoft.CSharp namespace. This is required by features like overload resolution for method calls have to happen at runtime instead of compile time. And because compiled programs take dependencies on this library, it is hard to change it without breaking deployed programs. The supporting libraries are so fragile that there is a policy to not change them [3].
As for why you would want this late-bound stuff in the first place, it is kinda nice when interfacing with dynamic language environments. When the feature was originally released, the Dynamic Language Runtime[4] was a big deal. It enabled implemented versions of Ruby and Python (called IronRuby and IronPython) that were based on .NET. And the "dynamic" keyword ease calling into these language implementations. Additionally calling into COM was made easier by the "dynamic" keyword. It was so useful that it was added back to .NET 5 [2].
[1]: https://docs.microsoft.com/dotnet/csharp/programming-guide/t...
[2]: https://github.com/dotnet/runtime/pull/33060
[3]: https://github.com/dotnet/runtime/issues/27790
[4]: https://en.wikipedia.org/wiki/Dynamic_Language_Runtime
> - Use LINQ cautiously as its variants are mostly slower than explicit coding. E.g. .Any() vs .Count == 0
Is this really true for the example? To me it seems that the implementation for .Any actually uses .Count when available, see https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...
In .NET 6 vs .NET 5 speedupI know the answers are yes.
Since we are on the topic of Linux so something exciting was merged for .Net6 that wasn't talked about; the new file interface with support for symbolic links. That sounds a bit absurd but it's been a long standing issue with challenges you wouldn't expect..
https://github.com/dotnet/runtime/pull/54253
In .NET 6 vs .NET 5 speedupDo be warned that .Net 6 did cause some regressions, in reflection at least
https://github.com/dotnet/runtime/issues/61486
In .NET 6 vs .NET 5 speedupYes, it embeds the CLR in to the application see the PR at https://github.com/dotnet/runtime/issues/43072
In .NET 6 Released> 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 ReleasedOn Linux, .NET does write ANSI escape sequences to stdout for you. ConsolePal.Unix.cs (Pal in this context referring to 'platform abstraction layer') does the work for you behind the scenes: https://github.com/dotnet/runtime/blob/10eb1a9ff1c09de4a2a1f...
In Anatomy of a Terminal EmulatorThe last remaining patches that enable FreeBSD on .NET have been merged upstream
6 points · Open discussionI wanted to ask you if the "-gsplit-dwarf" is a 100% complete alternative to strip the symbols as done previously. I ask you because some modern projects[1] still prefer to compile with symbols and strip afterward.
[1] https://github.com/dotnet/runtime/blob/main/eng/native/funct...
In Inspecting coredumps like it's 2021async/await makes things complicated - this is a great illustration of some issues with it. Fibers/green threads/goroutines seem to be generally easier and not viral. C#/dotnet choosing this the async model always bothered me. Otherwise, the platform is solid.
It's interesting, therefore, to try to understand why dotnet went with the async/await model.
A language maintainer C# talks about the issue here and references the rust justification for the same:
https://mail.mozilla.org/pipermail/rust-dev/2013-November/00...
https://github.com/dotnet/runtime/issues/11084
They knowingly seem to have chosen a more complicated model for performance. For me, that sounds like a bad trade. Developer time is quite a bit more valuable than compute time. The performance difference just doesn't seem to justify it.
In Asynchronous Programming in C#but if we assume that it works fine?
AFAIK there's ongoing and active work for FreeBSD
https://github.com/dotnet/runtime/issues/14537
In FreeBSD SSH HardeningLooks like .Net 6 (formerly Core), due for full release in a couple months supports M1 Macs[1] as a build target just fine. So does MAUI[2]
1. https://github.com/dotnet/runtime/issues/43313
2. https://docs.microsoft.com/en-us/dotnet/maui/get-started/ins...
In Containers Don't Solve EverythingThe C# compiler and parts of the supporting .NET runtime are written in C#, so yes there is a bootstrapping issue. Other languages like Rust or even C compilers written in C have this problem.
For initial porting to a new system or processor architecture, the C++ part of CoreCLR (the main runtime for .NET) can be built with CMake and LLVM on the target system. The libraries can be cross-compiled on another system that already supports .NET and copied to the target system. Some Details are here:
https://github.com/dotnet/runtime/blob/main/docs/design/core...
For building from source to satisfy requirements Linux distributions, Microsoft has a system to build from source. My understanding from the last time I closely looked at it is some binary dependencies are decompiled to MSIL (the bytecode used by .NET). Since CoreCLR includes a MSIL a
Read the rest
ssembler written in C++ (ilasm), it can bootstrap using these MSIL sources. But I have not looked at this project closely in a while and it evolved quite a lot while I was watching it. The system for the source build is here:
https://github.com/dotnet/source-build
CET = Control-flow Enhancement Technology
TL;DR:
> The ENDBRANCH (see Section 73 for details) is a new instruction that is used to mark valid jump target addresses of indirect calls and jumps in the program. This instruction opcode is selected to be one that is a NOP on legacy machines such that programs compiled with ENDBRANCH new instruction continue to function on old machines without the CET enforcement. On processors that support CET the ENDBRANCH is still a NOP and is primarily used as a marker instruction by the processor pipeline to detect control flow violations.
> The CPU implements a state machine that tracks indirect jmp and call instructions. When one of these instructions is seen, the state machine moves from IDLE to WAIT_FOR_ENDBRANCH state. In WAIT_FOR_ENDBRANCH state the next instruction in the program stream must be an E
Read the rest
NDBRANCH. If an ENDBRANCH is not seen the processor causes a control protection exception (#CP), else the state machine moves back to IDLE state.
Refs:
Above text: https://binpwn.com/papers/control-flow-enforcement-technolog... (from page 8, page 15 also has info)
"How do prior processors execute these?": https://stackoverflow.com/questions/56120231/how-do-old-cpus...
Random example of someone trying to leverage this capability to harden an app: https://github.com/dotnet/runtime/issues/40100
Random comment that has a bunch of semi-interesting info in it: https://news.ycombinator.com/item?id=26061230 (the bit about the lack of Linux support is potentially(?) out of date)
LWN article: https://lwn.net/Articles/758245/
Showing the 15 most recent of 34 sources. Enable JavaScript to search and browse every indexed mention.