Another link that had comments on it:
https://github.com/dotnet/corefx/issues/33115
In The Future of JSON in .NET Core 3.0dotnet
corefx
Languages & Compilers2014–2023
dotnet / corefx · Archived
corefx
This repo is used for servicing PR's for .NET Core 2.1 and 3.1. Please visit us at https://github.com/dotnet/runtime
69Distinct people
78Mentions
0Explicit recommenders
17.5KGitHub stars
What to know before exploring
What it is
This repo is used for servicing PR's for .NET Core 2.1 and 3.1. Please visit us at https://github.com/dotnet/runtime
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
- dotnet/coreclr · linked in 7 of the same discussions
- dotnet/roslyn · linked in 3 of the same discussions
- dotnet/runtime · 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 year78 dated mentions
Observed mentions: 2014-11-12 15:47:17 UTC to 2023-02-10 12:20:05 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 |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 17 | 5 | 12 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 15 | 4 | 11 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 8 | 4 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 16 | 0 | 16 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 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 | 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
9 sourcesThe Future of JSON in .NET Core 3.0
1 points · Open discussionLatest .net core 3 apparently supports single-bibary packaging.
It has been a often-requested feature for at least 2 years.
https://github.com/dotnet/corefx/issues/13329
(The last comment referring to warp is indicative)
In Warp – self-contained, single binary applicationsI think this is the github issue referred to:
https://github.com/dotnet/corefx/issues/23298
I wrote some replacement classes that address all of the known issues, here:
https://github.com/colgreen/Redzen/tree/master/Redzen/Random
https://www.nuget.org/packages/Redzen/
In Randomness in .NETI think the hard part here is not language design, it’s implementation of the runtime.
Linux is especially problematic, asynchronous IO has arrived late, years later than IOCP and kqueue. It took multiple kernel versions to make it usable, and still the APIs are questionable, e.g. files and sockets use different ones.
Even MS failed to do it right, see a bug I found: https://github.com/dotnet/corefx/issues/25066
In Async and Await in Rust: a full proposal.NET Core has pretty strong backwards compatibility rules:
https://github.com/dotnet/corefx/blob/master/Documentation/c...
> We generally don't accept change proposals that are in bucket #1.
...
> Bucket 1: Public Contract
Clear violation of public contract.
> Examples:
> - Renaming or removing of a public type, member, or parameter
> - Changing the value of a public constant or enum member
> - Sealing a type that wasn't sealed
> - Making a virtual member abstract
> - Adding an interface to the set of base types of an interface
> - Removing a type or interface from the set of base types
> - Changing the return type of a member
> - ...or any other incompatible change to the shape of an API
In .NET JIT and CLR – Joined at the HipFor Channel<T>, you can take a look at https://github.com/dotnet/corefx/tree/v2.1.0/src/System.Thre...
In Announcing .NET Core 2.1> Pretending an entire language barrier is the same as the barrier between Rust's safe/unsafe is kind of ridiculous.
I’m not pretending that. Just two points.
1. If you really need unsafe code, because raw pointers, or other reasons, C++ is safer than unsafe Rust.
2. If your project has two distinct parts, unsafe lower level, and safer higher level, you don’t need to use C++ for both. Real world software use multiple languages in the same project for decades already, e.g. QuakeC was developed in 1996.
> a regular expression library might use unsafe internally
If a library wants to do that, it probably means that safe language is too slow :-)
https://github.com/dotnet/corefx/tree/master/src/System.Text...
> I work heavily with finite automata.
I’m not saying Rust is useless. There are projects where it shines, and where I’d probably picked
Read the rest
it myself. Like a web browser CSS engine, or your finite automata, or many other things.
I’m saying that there’re large problem areas out there for which, due to various reasons, other languages are still way better than Rust. I do realize Rust evolves fast; eventually these areas might shrink or disappear. But in its current state, my opinion is the applicability is limited to very narrow areas: no bare metal, no SIMD, no GPU APIs, very limited asynchronous IO, limited embedded options, very limited numeric libraries, no GPGPU…
I’ve only listed the areas where I have recently (last couple of years) developed substantial amount of code in any other language.
It just happened that I didn’t work on either finite automata, nor browser CSS engines.
.NET Core didn't have DataSet/Table/View until v2.0. I'm still boggled by the idea that they think those are legacy (https://github.com/dotnet/corefx/issues/1039#issuecomment-77...) and that everybody will just use entity framework for everything.
In NET Core 2.1 Roadmap