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, 6:01:08 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

122 sources
keldaris·Dec 30, 2016
> Memory safety is important for everything because it is a prerequisite for any other form of correctness. That's obviously true, but not what I (or the OP) was talking about. My point was that in many applications memory safety doesn't rank highly as a separate concern, in addition to computing correct output from expected input. Because of this, describing Rust as a language that solely focuses on memory safety isn't very interesting to large groups of developers that work on such applications. > The rayon library offers similar functionality to OpenMP, including a parallel map/reduce (etc) over a vector, all in safe code for the user. I did look at rayon when I skimmed through the available ecosystem. The runtime cost of that approach wasn't obvious to me from the documentation, and it doesn't quite let me keep the loop-based control
Read the rest
flow usually employed for numerical calculations (because of the need to refer to different indices within the loop, etc.), but it's certainly a viable approach. Not a direct replacement to OpenMP loops, though. On the subject of -ffast-math, I did not encounter these recent additions you mention in the language documentation, but I'll take another look on the issue tracker and elsewhere. Thanks for the information. On tail call optimisations, I don't believe your statement is entirely correct. It's true that C++ compilers don't guarantee TCO (although, empirically they're very good at it), but Rust doesn't seem to be able to do it at all. It's explicitly stated in the language documentation and there's a recent issue on the subject [1]. And on explicit vectorization - I'll take a look at the latest nightly Rust and edit my post accordingly if explicit SIMD is already usable. Glad to hear it. FWIW, I think Rust has made great progress considering the age of the language, and I'm glad to see SIMD and other improvements being implemented. My objection was simply against the hyperbolic assertion that Rust has already attained full parity or even superiority over C++ in performance. By the way, is there a way to turn off runtime bounds checking for vectors? That's another common performance sink in numeric computing. [1] https://github.com/rust-lang/rust/issues/217
In Rust is mostly safety
duneroadrunner·Dec 29, 2016
> the compiler won't let me get it wrong. It's far far far too easy to screw up multithreaded code if you're using any kind of shared data, and Rust is the only language I know of that truly makes it safe without compromising on performance. While I am, in general, a fan of Rust's focus on safety, I think this particular feature (data race prevention) may actually be somewhat problematic in terms of making code safer. I'm worried that it may be sort of analogous to "all-wheel-drive" being marketed as a winter driving safety feature that ends up (perhaps apocryphally) causing more accidents because it instills a sense of overconfidence that results in drivers neglecting more important/effective safety practices (reduced speed, snow tires, etc.). I think it's beneficial to read one of the Rust issue threads, "Rust does not guarantee thread-
Read the rest
safety #26215"[1], about why they stopped referring to Rust as "thread safe". Data races only occur in the context of "casually" sharing objects between asynchronous threads. That is, accessing a shared object from asynchronous threads directly, instead of through a "fail-safe" access control mechanism. Some programmers may be of the position that directly accessing shared objects is perfectly fine in some contexts. In those cases Rust's data race safety feature is a plus. But data races are really just a subset of race conditions, and Rust doesn't prevent those other race conditions. The practice of directly accessing shared objects is prone to both (low-level) data races and (higher-level) "non-data race" race conditions. I'm worried that the larger effect of touting/marketing Rust's data race safety is to "(over-)legitimize/condone" the practice of "casually" sharing objects asynchronously, resulting in the neglect of prudent access control mechanisms (even if only by the inexperienced), and an increase in "non-data race" race condition bugs. So, in the interest of public safety, perhaps all-wheel-drive cars should be bundled with some sort of warning/notice that prudent winter driving practices (and speeds) should render all-wheel-drive almost irrelevant as a safety feature. And perhaps an analogous one for prudent asynchronous object sharing practices and Rust's data race safety. [1] https://github.com/rust-lang/rust/issues/26215 And a related article on safer asynchronous object sharing in C++ (shameless plug): https://www.codeproject.com/articles/1106491/sharing-objects...
In Rust is more than safety
michaelmior·Dec 28, 2016
> “Safe” code is guaranteed to be 100% safe. Not statistically safe. Not safe when the compiler feels like it. As long as your code compiles, it will be safe in terms of memory safety and data-race freedom. As far as I am aware, the Rust compiler has not been proved correct. So whether or not your code is correct still depends on the correctness of the compiler. Of course this is probably correct, but still not 100% guaranteed. Edit: Relevant discussion - https://github.com/rust-lang/rust/issues/9883
In Rust vs C Pitfalls
steveklabnik·Dec 22, 2016
Yes. It's a perfect storm of coincidences, basically. It's a combination of timing + a tiny feature. Let's take a step back. Macros 1.1 is RFC 1681: https://github.com/rust-lang/rfcs/blob/master/text/1681-macr... See the section saying "The initial implementation of librustc_macro is proposed to be incredibly bare bones:" it really is very, very small. So it landed, and while there was some questions that came up, people migrated to it, and it works well. 22 days ago, it was to be reviewed: https://github.com/rust-lang/rust/issues/35900#issuecomment-... However, two things happened: one, the Mozilla all-hands in Hawaii, which shook things up, but secondly, that meant a lot of people, including one of the reviewers, took PTO around that time, to actually see some of the islands. That includes someone who was on the reviewers list. So in ge
Read the rest
neral, "oh hey this is waiting on one person who forgot to check a box but isn't reachable now" is awkward. Luckily, in this case, we know that it was just forgetting to check the box; Felix did not have any objections that we were aware of. So we decided to sign off for him, and put it into FCP. This happened so that FCP technically passed the deadline for 1.15, but given how important it is to ship, we're planning on nominating it for a backport, and don't anticipate complaints. So: tiny feature, code wise. Big win for being stable. Procedural mishap involving awkward scheduling. All these things played into it. Make sense?
In Announcing Rust 1.14
cesarb·Dec 22, 2016
In this example, the loop bound is from the lhs, so llvm can prove that it will never get out of bounds and elide the bound checks. But llvm can't be sure that the rhs has the same size, so it can't elide the bound checks for the rhs. However, there's a trick. Take a look at https://github.com/rust-lang/rust/commit/6a7bc47a8f1bf4441ca... where the Rust developers had the same issue, and managed to avoid the bound checks without having to use unsafe code. You have to somehow make the optimizer see that both sides have the same length, so it'll elide both bounds checks. A slice is actually a pair of a pointer to the first element, and the length. Their trick copies the length from one slice to the other (after a bound check, obviously), so the compiler is sure that the lengths are the same.
In Four years with Rust
Gankro·Dec 4, 2016
Rust isn't hashcode based. You don't define how to hash a type in that way. You define hashing algorithms which operate on arrays of bytes. All a type has to do to implement hashing is specify how to feed its bytes into a hasher. Hashers provide conveniences for feeding in a u8, u16, u32, u64, etc., but most hashers just implement this as casting the value to an array of bytes and using the generic implementation. This is because most algorithms are defined in terms of bytes. Evidently there isn't any interesting optimization to do by statically knowing you have a u32 vs a u64 for these algorithms (appears to be the case for SipHash, XXHash, and Fnv). And indeed, u128 continues this tradition in the PR: https://github.com/rust-lang/rust/pull/37900/files#diff-2327...
In Rust: 128 bit integers preparing to be released

Showing the 15 most recent of 122 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.