HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
rust-lang
rust
Rust2012–2026
rust-lang / rust

rust

Empowering everyone to build reliable and efficient software.

Languages & Compilers
Explore on GitHubRead Hacker News discussions
818Distinct people
1,825Mentions
8Explicit recommenders
121.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Empowering everyone to build reliable and efficient software.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

10 years ago, I commented on the Rust issue for "Incremental recompilation", where it was suggested that Rust could at least adopt Haskell GHC's model of incrementality, which…

nh2 used a recommendation phrase. 11 indexed comments match. This is a phrase match, not a verdict.

Informational Commenters provide technical explanations for Rust's release cadence and design choices, such as the separation of stabilization processes and syntax tradeoffs. The discussion highlights consistent development practices and detailed reasoning behind language features.

What changed this week. Read the supporting reply

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Informational

Commenters provide technical explanations for Rust's release cadence and design choices, such as the separation of stabilization processes and syntax tradeoffs. The discussion highlights consistent development practices and detailed reasoning behind language features.

Supporting reply 1 · Supporting reply 2 · 4 discussions summarized

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 8:59:20 PM UTC.

Rust 1.100 direct repository linkDebated

The discussion highlights significant new features in Rust 1.100, such as the stabilized never type and unused dependency warnings, while sparking a substantive debate over whether the language's lack of a stable ABI is a necessary trade-off for its generic system or an impediment to library distribution. Participants clash between those viewing the current source-only model as sufficient and those arguing that a native stable ABI is essential for practical binary interoperability.

66 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4
Rust 1.100 direct repository linkDebated

The discussion centers on Rust 1.100.0, highlighting major stabilizations like the never type and custom allocators while noting that some APIs were omitted from the initial summary. A significant portion of the thread debates the feasibility and necessity of a stable ABI, with technical explanations contrasting against user desires for precompiled libraries.

47 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4
Systemd Loves Rust direct repository link

Read the discussion on HN. A full-thread summary is not available yet.

Showing the three threads with the most distinct people linking this repo, from 51 threads this week.

Mentions over time

HN mentions by year1,825 dated mentions

Observed mentions: 2012-01-20 23:03:27 UTC to 2026-10-22 06:16:46 UTC.

0501001502012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 42 mentions; 6 submissions, 36 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 82 mentions; 6 submissions, 76 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 138 mentions; 6 submissions, 132 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 114 mentions; 9 submissions, 105 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 122 mentions; 5 submissions, 117 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 119 mentions; 12 submissions, 107 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 88 mentions; 1 submissions, 87 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 115 mentions; 11 submissions, 104 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 166 mentions; 20 submissions, 146 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 149 mentions; 12 submissions, 137 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 151 mentions; 25 submissions, 126 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 167 mentions; 12 submissions, 155 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 132 mentions; 11 submissions, 121 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 158 mentions; 8 submissions, 150 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 82 mentions; 14 submissions, 68 comments. Incomplete calendar period.2026*

* 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
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC42636
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC82676
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC1386132
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC1149105
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC1225117
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC11912107
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC88187
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC11511104
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC16620146
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC14912137
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC15125126
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC16712155
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC13211121
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC1588150
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC821468

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Website | Getting started | Learn | Documentation | Contributing This is the main source code repository for Rust. It contains the compiler, standard library, and documentation. Why Rust? Performance: Fast and memory-efficient, suitable for critical services, embedded devices, and easily integrated with other languages. Reliability: Our rich type system and ownership model ensure memory and thread safety, reducing bugs at compile-time. Productivity: Comprehensive documentation, a compiler committed to providing great diagnostics, and advanced tooling including package manager and build tool (Cargo), auto-formatter (rustfmt), linter (Clippy) and editor support (rust-analyzer). Quick Start Read "Installation" from The Book. Installing from Source If you really want to install from source (though this is not recommended), see INSTALL.md. Getting Help See https://www.rust-lang.org/community for a list of chat platforms and forums. Contributing See CONTRIBUTING.md. For a detailed explanation of the compiler's architecture and how to begin contributing, see the rustc-dev-guide. License Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with portions covered by various BSD-like licenses. See LICENSE-APACHE, LICENSE-MIT, and COPYRIGHT for details. Trademark The Rust Foundation owns and protects the Rust and Cargo trademarks and logos (the "Rust Trademarks"). If you want to use these names or brands, please read the Rust language trademark policy. Third-party logos may be subject to third-party copyrights and trademarks. See Licenses for details.
Read the full README on GitHub

What Hacker News says

167 sources
Arnavion·Dec 29, 2023
>It absolutely was No, there is no such absolute requirement that "newly added" functions cannot be stabilized. Off the top of my head: https://github.com/rust-lang/rust/issues/111544 `OsStr::as_encoded_bytes` was proposed in 2023-05, finished being implemented in 2023-07, stabilized in 2023-09, and released in 2023-11. >https://news.ycombinator.com/item?id=38801228 The reason attr of "newly added" is the reason to *mark the function unstable* when it was implemented. It's not the reason to *prevent it from being stabilized.*
In You can't do that because I hate you
shepherdjerred·Dec 29, 2023
That annotation hasn't been touched (aside from being moved around) since it was authored [0]. Your comment said: > `Result::into_ok`, which was introduced in 2019, but is still unstable due to being "newly added". Your comment makes it sound that the Rust team considers a four year old utility method as "newly added", and that's the reason why this method is marked as unstable. More likely, this "newly added" reason is something they add for any new unstable feature, and it is now out of date. Considering that repository has 9,000 open issues, and 50,0000 total issues, you can imagine that this issue has simply not been prioritized. Rust being poor at prioritizing, handling issues, etc. is a totally separate discussion from "Rust thinks four year old code is new" [0]: https://github.com/rust-lang/rust/commit/c784720f3a2d0b66142...
In You can't do that because I hate you
Arnavion·Dec 28, 2023
Right, it's nothing to do with it being "newly added". That issue had been filed by its OP as a feature request. It then got repurposed into a tracking issue for the feature, but it's not following the standard tracking issue template that lists any blockers, stabilization steps, etc. (Compare to https://github.com/rust-lang/rust/issues/119364 that happens to be the newest "Tracking issue" atm.) Also since the OP didn't intend for it to be the tracking issue, it's possible they're not intending to do the rest of the bureaucracy to get it stabilized either, which is why it's stalled.
In You can't do that because I hate you
aw1621107·Dec 19, 2023
I'm not sure I'd call the design "bad". At the very least it's a product of the design constraints, and I'm not sure there's an obviously better implementation without sacrificing something else. I think separate compilation and monomorphization are the biggest contributors, but I wouldn't be surprised if there was something I was forgetting. Somewhat related, there was some work in Rust about sharing monomorphized generics across crates, but it appears it was not a universal win at the time[0]. I'm not sure if anything has changed since that point, unfortunately, or if something similar could be applied to C++ somehow. [0]: https://github.com/rust-lang/rust/issues/47317#issuecomment-...
In C++ Should Be C++
jstasiak·Dec 19, 2023
Looks like a great initiative – I wish there was a reliable TS/JS equivalent of https://docs.rs (even considering rustdoc's deficiencies[1]). I went through this exercise recently and so far my experience with trying to produce documentation from a somewhat convoluted TS codebase[2] has been disappointing. I would claim it's a consequence of the library's public (user-facing) API substantially differing from how the actual implementation is structured. Typedoc produces bad results for that codebase so sphinx-js, which I wanted to use, doesn't have much to work with. I ultimately documented things by hand, for now, the way the API is meant to be used by the user. Compare: https://ts-results-es.readthedocs.io/en/latest/reference/api... vs https://tsdocs.dev/docs/ts-results-es/4.1.0-alpha.1/index.ht... https://www.jsdocs.io/package/ts-result
Read the rest
s-es#package-index [1] https://github.com/rust-lang/rust/issues/66249 [2] https://github.com/lune-climate/ts-results-es
In Tsdocs.dev: Type docs for any JavaScript library
estebank·Dec 19, 2023
> If the compiler claims to follow the specified version of the spec, and it doesn't, you file a compiler bug. > And then use the subset that it supports, perhaps by using an older spec if it supports that fully. Perhaps looking for alternative compilers that have better/full coverage of a spec. If you encounter rustc behavior that seems unintentional, you can always file a bug in the issue tracker against the compiler or language teams[1]. Humans end up making a determination whether the behavior of the compiler is in line with the RFC that introduced the feature. > "Supports the spec minus these differences" is still miles better than "any behaviour can change because the Rust 2.1.0 compiler compiles code that the Rust 2.1.0 compiler compiles". You can look at the Rust Reference[2] for guidance on what the language is supposed to be. It
Read the rest
is explicitly not a spec[3], but the project is working on one[4]. 1: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais... 2: https://doc.rust-lang.org/reference/introduction.html 3: https://doc.rust-lang.org/reference/introduction.html#what-t... 4: https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...
In Progress toward a GCC-based Rust compiler
nequo·Dec 18, 2023
> Rust doesn't really have the reputation of moving slowly to adopt new features There are some exceptions to this. Although there are possibly good reasons for such features moving slowly, a competing compiler could popularize them before they are stabilized in rustc. One example is generators[1] but there's a longer list in The Unstable Book.[2] [1] https://github.com/rust-lang/rust/issues/43122 [2] https://doc.rust-lang.org/stable/unstable-book/language-feat...
In Progress toward a GCC-based Rust compiler
lifthrasiir·Dec 16, 2023
As others pointed out, there also exists `bool::then` that always accepts a closure and doesn't have this issue. In fact both `bool::then` and `bool::then_some` are originated from a single RFC [1], and people unanimously agreed on `bool::then` but not `bool::then_some`, so the latter spun off its own issue [2]. It seems that `bool::then_some` was eventually accepted mainly due to the lack of better alternatives---there were enough people wanting the value form and other pairs of method names were considered better. [1] https://github.com/rust-lang/rfcs/pull/2757 [2] https://github.com/rust-lang/rust/issues/64260
In Bug in my code from compiler optimization [video]

Showing the 15 most recent of 167 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.