Odd indeed, given that .NET Native doesn't support it without a couple of hacks.
https://github.com/dotnet/corert/issues/5780
https://github.com/dotnet/fsharp/issues/1096
In Fable 3: F# to JavaScript compilerdotnet
corert
C#2015–2023
dotnet / corert · Archived
corert
This repo contains CoreRT, an experimental .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying compiler toolchain.
30Distinct people
50Mentions
0Explicit recommenders
2.9KGitHub stars
What to know before exploring
What it is
This repo contains CoreRT, an experimental .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying compiler toolchain.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:04:58 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year50 dated mentions
Observed mentions: 2015-11-18 17:03:58 UTC to 2023-05-26 14:21:26 UTC.
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 |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 9 | 0 | 9 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 17 | 2 | 15 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
.NET Core Runtime (CoreRT)
This project is superseded by NativeAOT experiment in dotnet/runtimelab repo.
This repo contains the .NET Core runtime optimized for ahead of time compilation. The CoreRT compiler can compile a managed .NET Core application into a native (architecture specific) single-file executable that is easy to deploy. It can also produce standalone dynamic or static libraries that can be consumed by applications written in other programming languages. To learn more about CoreRT, see the intro document.
Try Our Samples
If you would like to give CoreRT a try, we publish daily snapshots of CoreRT to a NuGet feed. Using CoreRT is as simple as adding a new package reference to your .NET Core project and publishing it. Check out one of our samples: a "Hello World" console app, a simple ASP.NET Core app, a MonoGame game or a native library. The README.md file in each sample's directory will guide you through the process step by step.
Platforms
Windows, MacOS and Linux x64 w/ RyuJIT codegen is able to compile many complex apps.
ASP.NET Core sample
MonoGame sample
Avalonia sample and demo video
ADO.NET sample
EntityFrameworkCore.Sqlite sample
Unsupported features: Dynamic loading (e.g. Assembly.LoadFile), dynamic code generation (e.g. System.Reflection.Emit), Windows-specific interop (e.g. COM, WinRT)
Linux ARM w/ RyuJIT codegen: ElmSharp Hello Tizen application (detailed status)
CppCodeGen (targets all platforms that support C++): Simple C# programs. The big missing features are garbage collection and exception handling.
WebAssembly: Early prototype that compiles and runs very trivial programs only. Many features are not yet implemented.
How to Engage, Contribute and Provide Feedback
Some of the best ways to contribute are to try things out, file bugs, and join in design conversations.
Looking for something to work on? The up for grabs issues are a great place to start. Take a look at our documentation to find out about the architecture and learn how to build and test the repo.
This project follows the .NET Core Contribution Guidelines.
.NET Native for UWP Support
Use https://developercommunity.visualstudio.com/ to report problems and suggestions related to .NET Native for UWP.
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.
License
The CoreRT Repo is licensed under the MIT license.
.NET Foundation
CoreRT 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.
Related Projects
There are many .NET related projects on GitHub.
The .NET home repo links to 100s of .NET projects, from Microsoft and the community.
The ASP.NET Core repo is the best place to start learning about ASP.NET Core.
Read the full README on GitHubWhat Hacker News says
6 sourcesHere's the .NET 5 announcement which wraps up everything: https://devblogs.microsoft.com/dotnet/introducing-net-5/
.NET windows/desktop framework stopped at version 4.8 and .NET Core has spent 4 years incrementing to version 3, so .NET 5 is a merger of everything into a single framework again. Mono will still exist since it's used by Xamarin for mobile and Unity for games.
AOT is mentioned in the article and comments, and there's also this big thread in the CoreRT repo if you want to see more discussions: https://github.com/dotnet/corert/issues/7200
In .NET OrleansCorert – experimental .NET Core runtime optimized for AOT
4 points · Open discussionI just really wish they start investing into true static compilation for .NET.
Some serious projects [1] started adopting CoreRT [2], despite Microsoft's neglect for their own runtime. CoreRT seems to really deliver on the single-file fast-startup small-size .NET promise. Getting this project folded into the LTS .NET 6 release should be a priority.
The source generators [3] that are coming to .NET 5 easily cover 99% of our Reflection.Emit use cases, so the JIT is going to be more of a legacy burden once .NET 5 comes out.
I want Go's small size, fast compile times, fast startup, without Go's bs (explicit error checking, seriously?).
Pieces of our software get deployed over a satellite link so yeah, megabytes matter (and that's why I don't even dare to propose using .NET for those parts). Sharing code with the rest of our .NET stack is a PI
Read the rest
TA though so people are getting itchy to rewrite the rest of our .NET stuff in Go for better sharing (the Reflection.Emit parts would be replaced with "go generate" which is... a source generator). It would be good to get some clarity on the static compilation roadmap in .NET because I like my job, but I also don't want to become a fulltime Go developer.
[1] https://github.com/dotnet/corert/issues/7200#issuecomment-62...
[2] https://github.com/dotnet/corert
[3] https://devblogs.microsoft.com/dotnet/introducing-c-source-g...
>Just like the JVM and CLR I guess. (List_of_JVM_languages, List_of_CLI_languages)
I don't see JVM & CLR even with the dozens of language choices on top of the virtual machine runtimes as giving you ways to do "bare metal" programming. I guess one could arguably squint and say Java's JNI or C# P/Invoke and "unsafe{}" gets you some "bare metal" capabilities but that's a stretch.
I go back to the gp's sentence: "Imagine starting a project in an easy language, then migrating pieces to a faster "bare metal" language as needed in a super piecemeal way."
For example, JVM/Java doesn't have value types[1] (yet) and that's required for programmer's control of exact and efficient memory layout for many bare metal domains. It doesn't matter what flavor of JVM language you use because you're ultimately limited by the JVM's capabilities which cause
Read the rest
s excessive pointers to pointers which is inappropriate for some high-performance code.
In C#, some future tech like CoreRT might open up some more "bare metal" programming possibilities but that's not production yet[2]. I remember you couldn't even develop a Windows Explorer right-click menu shell extensions in C# because it was a bad idea to load up 2 different versions of the NET Framework runtimes (until NET 4.0). That's not even that low a level of programming and yet C++ had no such limitation.
I use C# as much as I can but I still have to do 50% my projects in C++ because JVM/CLR are not "bare metal" enough.
[1] https://en.wikipedia.org/wiki/Criticism_of_Java#Compound_val...
[2] https://github.com/dotnet/corert#user-content-net-core-runti...
I think was true before .NET Core, but now the experience is quite good.
It's also possible to use F# as a compile-to-js language using Fable. This code would run on Node or the browser.
Then there is https://github.com/dotnet/corert which allows ahead-of-time compilation to native code, but it is a bit more experimental.
In F# Data Type Providers in .Net Core (2018)