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
96 sourcesJS, Java and C# have vastly different implementation details each.
Java uses type erasure for generics. .NET uses generic monomorphization for struct-typed generic arguments and method body sharing with virtual/interface dispatch for class-typed generic arguments (the types are never erased).
Moreover, non-capturing lambdas do not allocate, and are also get speculatively inlined by the JIT behind a guard. It's a bit limited but works quite well in production applications. You can also write struct-based iterators in C#. The main limitation is lack of full HM type inference which means having less convenient API where you can't convince the compiler to infer the full type signature.
One of the current limitations of C# is that lambdas are of type Func<T1...Tn, TResult> - calls through them are virtual. So unless JIT emits a guarded devirt
Read the rest
path - you cannot specialize over them like over Fns in Rust which are part of the monomorphized generic signature. Various performance-oriented libraries sidestep this by implementing "value delegate" pattern where you constrain an argument over an interface implementation of an invoke-like method. Basically doing the higher order functions via struct implementations.
Java here also deserves a mention because OpenJDK is capable of inlining of shallow streams - Stream API is moderately to significantly slower than LINQ but it's not terribly slow in absolute terms.
With all that, in the recent versions, LINQ has started encroaching on the territory of performance of Rust iterators especially on large sequences where access to faster allocations and heavy pooling of underlying buffers when collecting to an array or a list allow for very efficient hot paths. LINQ also does quite a bit of "flattening" internally so chaining various operators does not necessarily add extra layer of dispatch.
Lastly, F# is capable of lambda inlining together with the function accepting it at IL level at build time and does so for various iterator expressions like Array.map, .iter and similar. You access this via `inline` bindings and `[<InlineIfLambda>]`-annotated parameters. It is also possible to implement your own zero-cost-ish iterators with computation expressions. If JIT/ILC improves at propagating exact types through struct fields in the upcoming release, it will be able to inline F# lambdas even if expansion does not happen at IL level: https://github.com/dotnet/runtime/issues/110290
NB: auto-vectorization is extremely fragile even with LLVM and kicks in only in simple scenarios, the moment you have a side effect a compiler cannot reason about it stops working.
The 2-4 speed ratio was not meant to denounce C#, which is a great language I loved to program in for over two decades, coming from Delphi.
Unfortunately, C# has not a complete SIMD support.
See our request to support the SSE4.2 _mm_cmpistrm instruction https://github.com/dotnet/runtime/discussions/63332, which we required for a vectorized intersection between two sorted 16-bit arrays.
We did the switch from C# to Rust not light-minded, as the cost of porting a fairly large codebase is time-consuming.
We just wanted to share our experience for our specific task, not as a general statement.
In Show HN: SeekStorm – open-source sub-millisecond search in RustThe referencesource repository is only relevant if you are using the legacy .NET Framework. Modern .NET has a special case for passing a List<Task> and avoids the allocation:
https://github.com/dotnet/runtime/blob/1f01bee2a41e0df97089f...
In How much memory do you need in 2024 to run 1M concurrent tasks?It doesn't take that much space, and not all languages have option to easily map an initial range onto an iterator that produces tasks. Most are dominated by the size of state machines/virtual threads.
Please note that the link above leads to old code from .NET Framework.
The up-to-date .NET implementation lives here: https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...
In How much memory do you need in 2024 to run 1M concurrent tasks?Unthinkable crutches in Go land continue.
This is something that needs to be fixed in the runtime itself to be appropriately container-aware and not require the users to write their own libraries to patch this out.
For example: https://github.com/dotnet/runtime/pull/99508
(alternatively, the goroutine runtime could have been made auto-scalable which would have reduced the impact at the cost of implementation complexity, like .net's threadpool is)
In Go Production Performance Gotcha – GOMAXPROCSIf you're interested, here's the overview of planned compiler work for .NET 10: https://github.com/dotnet/runtime/issues/108988
Autovectorization is usually very fragile and in areas where you care about it hand-written implementation always provides much better results that will not randomly break on minor changes to compiler version or the code, that must be carefully guarded against.
It would be still nice to have it eventually, and I was told that JIT team actively discusses this but there are just many more lower hanging fruits that will light up in disproportionately more instances of user code.
If it's any consolation, Clang/LLVM is not a silver bullet either and you will find situations where .NET's compiler output is competitive or even better: https://godbolt.org/z/3aKnePaez
In The two factions of C++.NET's compiler does not perform loop autovectorization as it has not been as profitable of a compiler throughput investment as other optimizations (but it does many small optimizations that employ SIMD operations otherwise like unrolling string and span comparisons, copies, moving large structs, zeroing, etc., it also optimizes the SIMD operations themselves ala LLVM).
.NET does however offer best-in-class portable SIMD API and large API surface of platform intrinsics both of which are heavily used by CoreLib and many performance-oriented libraries. You can usually port intrinsified implementations hand-written in C++ to C# while making the code more readable and portable and not losing any performance (though sometimes you have to make different choices to make the compiler happy).
https://github.com/dotnet/runtime/blob/main/docs/coding
Read the rest
Reading through the JEP again it does not seem to be related - it is about deprecating unsafe APIs that the executed code itself uses. OpenJDK also has "partial escape analysis" where the object that only conditionally escapes can still be placed on the stack/scalar replaced.
I'm not privy to the exact APIs that OpenJDK exposes but in .NET the main limitation around escape analysis that spans multiple methods is the fact that CoreCLR has re-JIT API which allows to perform a multitude of actions like attaching a profiler or a debugger to a live application and forcing the runtime to deoptimize a particular method for debugging, or modifying the implementation and re-JITting the result. Debug codegen is very different especially around GC liveness tracking and escape analysis that builds on top of it - it means that even debug code would ha
Read the rest
ve to uphold stack-allocated nature of such object in some way, complicating the design significantly. In addition to that, debuggers and other instrumentation may observe object references that would have otherwise not escaped local scope.
This creates an unfortunate situation where the above almost never happens in production, but ignoring it and "just stack-allocating anyway" would lead to disastrous breakage for all sorts of existing instrumentation. Because Go does not have to deal with this constraint, it can perform interproc escape analysis without risk - whether a pointer escapes or not can be statically proven. For NativeAOT, .NET could approach this problem in the same way, but paraphrasing compiler team: "We would like to avoid optimizations only available for one of the target types be it JIT or AOT, and only supporting AOT would not benefit the majority of the .NET users".
There is, however, recognition that more comprehensive interproc analysis could be very beneficial, including the EA which is why it is planned to work on it in .NET 10:
- https://github.com/dotnet/runtime/issues/108931 IPA framework
- https://github.com/dotnet/runtime/issues/104936 Stack allocation enhancements
Note that Blazor has serious deployment problems since ~2021 [0] due to MS picking some idiotic packaging format defaults.
I.e. Let's make it look like a Windows executable! And go ahead and name it .dll! I'm sure no default firewall settings will have an issue with that.
So any wide Blazor app deployment also requires overriding the default packaging and adding obfuscation.
Supposedly that's experimentally fixed in NET 8... [1]
[0] https://github.com/dotnet/aspnetcore/issues/31048
[1] https://github.com/dotnet/aspnetcore/issues/36978#issuecomme... https://github.com/dotnet/runtime/issues/80807
In Uno Platform Studio: GUI Designer for Cross-Platform .NET ApplicationsI think the new locking abstraction could be considered somewhat significant.
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
https://github.com/dotnet/runtime/issues/34800
https://github.com/dotnet/runtime/issues/34812
In .NET 9 Is OutAsk HN: Has Anyone Tried Single File Development with IDE Code Collapse?
I've been exploring a different approach to organizing my projects by keeping all the code in a single file and taking advantage of the code collapse feature available in most modern IDEs. I'm curious if anyone else has tried this and what their experiences have been.
One of the primary benefits I've found is easier code portability. With all the code in a single file, you can simply drop the file into your project without worrying about dependencies or file organization. Refactoring also becomes more straightforward since you can see all the related code in one place, making it easier to update dependencies and related functions. Additionally, LLM assistants often perform better with code completion when all the code is in one file, as they can access the entire context more easily.
I've noticed that other projects also take a single fil
Read the rest
e approach. For instance, SQLite concatenates all its C files when it's built, there are single file header projects like STB^1 that tout ease of use, and even the .NET garbage collector^2 is a single 56k file. So, this approach is not entirely unprecedented. With modern editing tools, this method seems more viable than ever before. What does everyone think?
1. https://github.com/nothings/stb
2. https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/gc.cpp
This might be more problematic under CoreCLR than under Unity. Prematurely invoking GC will cause objects that are more likely to die in Gen 0 to be promoted to Gen 1, accumulate there and then die there. This will cause unnecessary inter-generational traffic and will extend object lifetimes longer than strictly necessary. Because live object count is the main factor that affects pause duration, this may be undesirable.
It might be more useful to use OSU! approach as a reference: https://github.com/dotnet/runtime/issues/96213#issuecomment-...
OSU! represents an extreme case where the main game loop runs at 1000hz, so for much more realistic ~120hz you have plenty of options.
In A comparison of Rust’s borrow checker to the one in C#"Vanilla" .NET runs on
Operating Systems: Linux, macOS, Windows, FreeBSD, iOS, Android, Browser
Architectures: x86, x86_64, ARMv6, ARMv7, ARMv8/ARM64, s390x, WASM
Notes:
Mono as referred here means https://github.com/dotnet/runtime/tree/main/src/mono which is an actively maintained runtime flavor, alongside CoreCLR.
- Application development targets on iOS and Android use Mono. Android can be targeted as linux-bionic with regular CoreCLR, but it's pretty niche. iOS has experimental NativeAOT support but nothing set in stone yet, there are similar plans for Android too.
- ARMv6 requires building runtime with Mono target. Bulding runtime is actually quite easy compared to other projects of similar size. There are community-published docker images for .NET 7 but I haven't seen any for .NET 8.
- WASM also uses Mono for the time being. There i
Read the rest
s a NativeAOT-LLVM experiment which promises significant bundle size and performance improvements
- For all the FreeBSD slander, .NET does a decent job at supporting it - it is listed in all sorts of OS enums, dotnet/runtime actively accepts patches to improve its support and there are contributions and considerations to ensure it does not break. It is present in https://www.freshports.org/lang/dotnet
At the end of the day, I can run .NET on my router with OpenWRT or Raspberry Pi4 and all the laptops and desktops. This is already quite a good level given it's completely self-contained platform. It takes a lot of engineering effort to support everything.
There is a runtime (not C#) feature that has been added that is relevant to the article: ref fields in structs. Before these, only certain runtime-blessed types like Span<T> could contain refs directly.
In case anyone is interested, here is the spec about refs in structs and other lifetime features mentioned in the article:
https://github.com/dotnet/csharplang/blob/main/proposals/csh...
And here is the big list of ways .NET differs from the publish ECMA spec. Some of these differences represent new runtime features.
https://github.com/dotnet/runtime/blob/main/docs/design/spec...
In A comparison of Rust’s borrow checker to the one in C#Garbage collection is solved to the extent that host garbage collection is now available via WasmGC:
https://developer.chrome.com/blog/wasmgc/
https://v8.dev/blog/wasm-gc-porting
But languages like C# want more features in WasmGC:
https://github.com/dotnet/runtime/issues/94420
No direct DOM access yet. You still have to use JavaScript glue code to get at the DOM.
In Should JavaScript be split into two languages?Showing the 15 most recent of 96 sources. Enable JavaScript to search and browse every indexed mention.