Have they decided not to support FreeBSD, or it's just extremely low priority? I could swear I remember that being listed as a supported platform early on in the project.
Edit: Ahh, okay, "Support the community extending CoreCLR in various ways (e.g. FreeBSD support)" https://github.com/dotnet/coreclr/blob/master/Documentation/...
In .NET Core Roadmapdotnet
coreclr
Languages & Compilers2015–2025
dotnet / coreclr · Archived
coreclr
CoreCLR is the runtime for .NET Core. It includes the garbage collector, JIT compiler, primitive data types and low-level classes.
97Distinct people
137Mentions
2Explicit recommenders
12.8KGitHub stars
What to know before exploring
What it is
CoreCLR is the runtime for .NET Core. It includes the garbage collector, JIT compiler, primitive data types and low-level classes.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
> ... is one of my favorite side effects of it being open sourced. Agree! I would never have the time or expertise to work all this out just using WinDBG or similar. Having the…
matthewwarren used a recommendation phrase. 2 indexed comments match. 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/corefx · linked in 7 of the same discussions
- dotnet/roslyn · linked in 4 of the same discussions
- aspnet/mvc · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:56:55 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 year137 dated mentions
Observed mentions: 2015-02-03 18:07:42 UTC to 2025-04-14 18:28:02 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 | 44 | 6 | 38 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 23 | 3 | 20 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 24 | 5 | 19 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 17 | 3 | 14 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 23 | 3 | 20 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-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
Going forward, the .NET team is using https://github.com/dotnet/runtime to
develop the code and issues formerly in this repository.
Please see the following for more context:
dotnet/announcements#119 "Consolidating .NET GitHub repos"
Read the full README on GitHubWhat Hacker News says
23 sourcesFrom how I read this comment, it's not exposed on x86 because it's extremely slow on Atom:
https://github.com/dotnet/coreclr/blob/cb9cbef5cd036bb761720...
In KestrelHttpServer SuperCharged MemoryPoolIteratorYes, you can find it on github. [1]
[1] https://github.com/dotnet/coreclr
In Google joins .NET Foundation as Samsung brings .NET support to TizenProbably some variation of https://github.com/dotnet/coreclr/tree/master/src/pal . I know it's also used for something else relating to VS but I forget what.
In Microsoft announces the next version SQL Server for Windows and LinuxHere are a few in no particular order:
1. Expert .NET 2.0 IL Assembler (ISBN 1590596463)
2. Advanced Windows Debugging (ISBN 0321374460)
3. Advanced .NET Debugging (ISBN 0321578899)
4. .NET Framework reference source code (https://referencesource.microsoft.com/)
5. CoreCLR source code (https://github.com/dotnet/coreclr)
6. MSDN documentation (it's not perfect, but it's not all bad)
Before CoreCLR was open source, I had to rely on Shared Source Common Language Infrastructure (https://en.wikipedia.org/wiki/Shared_Source_Common_Language_...).
In Eagle: Tcl interpreter implemented in CLRCompact String implementation in the CLR (proposal)
2 points · Open discussionmore info on this issue - https://github.com/dotnet/coreclr/issues/25
In .NET Framework 4.6.2Yeah, please try again. The problem with a lot of Connect programs is that they were tied to a specific release (MonkeyManager Pro 2008) so bugs that didn't make the cut for the product release just got lost in space (not picked up for MonkeyManager Pro 2010). Part of the reason was that there were always internal bug tracking systems, which was what the dev team was really working from day to day, and these other systems were just inputs to that.
If you look at any of the projects that are on GitHub now, the public issues list is the issues list. You can see all the dev comments, scheduling via labels, pull requests, code reviews, etc.
https://github.com/aspnet/mvc/issues?q=is%3Aissue+is%3Aclose...
https://github.com/dotnet/coreclr/issues?q=is%3Aissue+is%3Ac...
For products that aren't on GitHub, public issue lists like UserVoice have st
Read the rest
ill been a big improvement (in my opinion) because they usually keep the bugs / issues / feedback around until it's fixed, and the votes accumulate so the important issues keep bubbling up.
* FreeBSD is listed on CoreCLR GitHub repo (https://github.com/dotnet/coreclr).
See current build status here: http://dotnet-ci.cloudapp.net/job/dotnet_coreclr/job/master/...
* Also, see doc here (last updated in feb though): https://github.com/dotnet/coreclr/blob/master/Documentation/...
* Laslty, FreeBSD arrived on azure last week, so it would be quite surprising if support was dropped.
In Announcing .NET Core 1.0There's a couple of issues on the CoreCLR GitHub page that touch on this idea, i.e. a replacement GC, see
- https://github.com/dotnet/coreclr/issues/732
- https://github.com/dotnet/coreclr/issues/430
In-particular this comment https://github.com/dotnet/coreclr/issues/430#issuecomment-78...:
> The "alt-gc" direction is possible, but not as easy.
> The GC features that the CoreCLR runtime depends on (for full functionality) are pretty rich. It includes features that are not always found in experimental GC implementations out there such as interior pointers or pinning. It is non-trivial to build an alternative implementation of the rich advanced feature set.
> Integrating a new GC was actually done as research project back in 2003 on top of Rotor. Some of the difficulties highlighted by the project report are not valid anymore - the interf
Read the rest
ace between the CoreCLR runtime and GC is much cleaner than it used to be back in 2003. However, a lot of it is still holds - the issues listed in 5.1 "Integration Issues and Solutions" in particular.
The CoreCLR version of the .NET Garbage Collector can be found at https://github.com/dotnet/coreclr/tree/master/src/gc
In Visualising the .NET Garbage CollectorNot sure if this is the same exact GC because the family tree of .NET Core is complicated, but the CoreCLR project has a GC here:
https://github.com/dotnet/coreclr/tree/master/src/gc
In Visualising the .NET Garbage CollectorThere is an amusing comment in the CLR about it's support for odd length BSTRs[0]. There can be an extra wchar after the null terminator to store the extra byte.
It looks like if you use the automatic BSTR marshaler it creates a copy[1], though the CLR is so big it's hard for me to say that with confidence. Taking the address of a string with the fixed statement in C# of course won't allocate and that pointer can be passed to APIs that expected Unicode strings.
[0]: https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa18...
[1]: https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa18...
In Strings and the CLR – A Special RelationshipBefore the CLR was open sourced you could investigate how things were implemented by using decompilers on the MSIL code or later shared source, but but investgations often stopped at a InternalCall just as things started to get interesting. Now you can see the whole story of how abstractions are implemented part in C# and part in C++ when the runtime needs to "bend the rules" of what C# would normally allow. The corert[0] project is interesting because a larger portion of the run is implemented in C# (or as compilation passes instead of runtime code generation). For example, you can find exception dispatch and type casting implemented in C# there [1].
One example from the article that may be a little off is getting the length of string. It looks like the call to string.get_Length is probably replaced with a JIT intrinsic[2]. The importer
Read the rest
then turns that intrinsic call into a GT_ARR_LENGTH[3] node that is eventually lowered into something like[4]:
*(stringAddr + offsetOfStringLengthField)
It's a bit more complicated than that, as there are several references to GT_ARR_LENGTH in various optimization passes.
[0]: https://github.com/dotnet/corert/
[1]: https://github.com/dotnet/corert/tree/master/src/Runtime.Bas...
[2]: https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa18...
[3]: (warning, big file) https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa18...
[4]: (warning, big file) https://github.com/dotnet/coreclr/blob/a123c3972c447c8bcfa18...
Showing the 15 most recent of 23 sources. Enable JavaScript to search and browse every indexed mention.