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 4rust-lang
cargo
Rust2014–2026
rust-lang / cargo
cargo
The Rust package manager
100Distinct people
151Mentions
1Explicit recommenders
15.7KGitHub stars
What to know before exploring
What it is
The Rust package manager
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I love Rust, but it's particularly frustrating to me how it (nearly) forces you to use a single centralized package repository. Shameless plug for an issue:…
gspr used a recommendation phrase. One indexed comment matches. 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
- rust-lang/rust · linked in 8 of the same discussions
- netflix/lipstick · linked in 2 of the same discussions
- rust-lang/rfcs · 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:02:50 PM UTC.
Mentions over time
HN mentions by year151 dated mentions
Observed mentions: 2014-03-19 04:01:54 UTC to 2026-10-01 11:59:02 UTC.
* 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
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 13 | 0 | 13 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 11 | 0 | 11 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 14 | 0 | 14 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 11 | 0 | 11 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 19 | 1 | 18 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 12 | 2 | 10 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 10 | 1 | 9 |
What Hacker News says
12 sourcesTHthe_white_oak·Dec 23, 2016
Yes, it did. Cargo had a bunch of features released ahead of time, see https://github.com/rust-lang/cargo/issues/3282.
In Announcing Rust 1.14A quick summary of where these are at:
Internationalization / Localization / Unicode (ICU): yup, no real progress. Needs some domain experts to drive it.
Date/Time : chrono is the most popular.
HTTP: hyper has been good for a few years now, tokio will make it async soon.
Crypto: there's lots of interesting work in this space, see ring and rustls.
SQL: Diesel is the gold standard here.
So, some progress! You're absolutely right that growing the crates ecosystem is vital; we've doubled our numbers in the last year, but there's always more to do.
> project templates
https://github.com/rust-lang/cargo/pull/3004
In Four years with Rusthttps://github.com/rust-lang/cargo/pull/2857
This will be nice. I couldn't possibly sell rust to my employers if we had to go to an outside source for packages like [EDIT: rust/crate currently does, with crates.io]. Being able to host our own mirrors (for CM purposes, if nothing else) is essential.
In Announcing Rust 1.12To be honest, this is the kind of thing that would be great to highlight immediately on https://github.com/rust-lang/cargo or http://doc.crates.io/guide.html.
I go to those pages and I am given 0 information on how the thing actually works.
In The Rust PlatformThere was some discussion about potentially using a SAT solver for cargo in this issue:
https://github.com/rust-lang/cargo/issues/2064
and graydon wrote a POC of using the Z3 solver to find a solution where semver constraints were satisfied, optimizing for the latest versions within those constraints:
https://github.com/graydon/z3-rs/blob/master/tests/semver_te...
In Comparison of Programming Language Package ManagersOne thing about Cargo's lack of 'vendoring' on the checkmark list; there is https://github.com/alexcrichton/cargo-vendor , and soon there will be https://github.com/rust-lang/cargo/pull/2857
In Comparison of Programming Language Package Managershttps://github.com/rust-lang/cargo/issues/2064
From my perspective: one of the biggest issues in cargo right now. I know it's not the same as the HP problem, but current cargo is definitely not good at solving this.
In The Rust PlatformFor some context on point 1, https://github.com/rust-lang/cargo/pull/2857
In Shipping Rust code in Firefoxhttps://github.com/rust-lang/cargo/pull/2405 landed, but https://github.com/rust-lang/cargo/issues/2082 is similar too and is still open.
In Cargo: predictable dependency management> it should put things in $XDG_CONFIG_HOME and $XDG_CACHE_HOME
I was going to submit an issue but one already exists [1][2]
[1] https://github.com/rust-lang/cargo/pull/148
[2] https://github.com/rust-lang/cargo/issues/1734
In Cargo: predictable dependency managementYeah, the Cargo.lock file means that * constraints aren't a problem until you need to update a library, e.g. to get an emergency bug fix. And, you are right that cargo update's --precise option allows manually getting the same benefits of explicit requirements, but even doing this once seems like more work than just including the right version, especially with the risk of `update`ing wrong (although, again, Cargo.lock can save you here, if you're tracking it in version control). The combination of `cargo search` (built-in) and `cargo add` (external, others have linked it) makes it pretty easy to just add the right versions at the outset.
> I'd also note that while theoretically restricting versions works, in practice having multiple versions of a single crate within a rust project often leads to build failures due to crate A having a publ
Read the rest
ic API that uses types from crate B, and crate C using both, but not getting the same version of B that A got. This leads to type errors at build time.
This is a problem, yes, but focusing on it by itself is somewhat of a red-herring: if A doesn't restrict B's version there's no guarantee that A compiles against whatever version of B that happens to be chosen, i.e. you don't even get to the point where there could be problematic interactions.
In any case, there has been serious discussion about how cargo can solve the problem of crates exposing other crates in their API, and the current proposed solution is to make cargo more strict about allowing multiple versions of such crates. #2064 is the relevant issue.
https://github.com/rust-lang/cargo/issues/2064