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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:30:57 AM 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 sourcesEPepage·Dec 29, 2024
> The one goal of the port we did not succeed in was removing CMake.
> That’s because, while cargo is great at building things, it is very simplistic at installing them. Cargo wants everything in a few neat binaries, and that isn’t our use case. Fish has about 1200 .fish scripts (961 completions, 217 associated functions), as well as about 130 pages of documentation (as html and man pages), and the web-config tool and the man page generator (both written in python).
Our issue for this is https://github.com/rust-lang/cargo/issues/2729
Personally, I lean away from Cargo expanding into these use cases and prefer another tool being implemented on top. I've written more about this at https://epage.github.io/blog/2023/08/are-we-gui-build-yet/
In Fish 4.0: The Fish of Theseus> cargo install marmite
I'm not the only one (1) that believes this is wrong direction for cargo, and is abusing it's intent and purpose.
If you want to distribute an application, there are lots of ways to do that. If it's a developer tools, for developers, `cargo install` might be suitable, sure... but I think there's a fair argument to be made that if you want a tool:
git clone foo
cd foo
cargo install --path .
Is an explicit, safe and less error prone way of doing it.
...and one that doesn't walk us down the road of (see the linked thread) the obvious desire people are going to have sooner or later to cache binary builds instead of building locally, and turn `cargo install` into some kind of binary application distribution application or app store.
If you don't believe me, read that thread, and the linked thread.
[1] - htt
In Show HN: Marmite – Zero-config static site generatorJust look at the proposal to add an --only-dependencies flag to cargo-build.
https://github.com/rust-lang/cargo/issues/2644
Its a clusterfuck of people misdirecting the discussion, the maintainers completely missing the point, and in the end its still not even been allowed to start.
Cargo can download-only, it cant build only dependencies. If you, for whatever reason (ignoring the misleading docker examples) want to build your dependencies separately from your main project build, you are sol unless you want to use a third party dependency to do so.
In Rewriting RustWork, is being done, though: https://github.com/rust-lang/cargo/issues/13873.
In Comfy, the 2D rust game engine, is now archived> Rust has lock files, so breaks will only happen when you decide they are allowed to happen, by running cargo update.
great in theory but ``cargo install`` will straight up ignore lockfiles by default[0], meaning trying to install a binary package is a roulette of "did this tiny package update before everyone in the dependency tree noticed"
[0]: https://github.com/rust-lang/cargo/issues/7169
In Comfy, the 2D rust game engine, is now archivedThe more I've been doing open source maintenance and contributions where there isn't as much context between the code author and reviewer, the more I've been pushing for a little more than this.
- Add tests in a commit *before* the fix. They should pass, showing the behavior before your change. Then, the commit with your change will update the tests. The diff between these commits represents the change in behavior. This helps the author test their tests (I've written tests thinking they covered the relevant case but didn't), the reviewer to more precisely see the change in behavior and comment on it, and the wider community to understand what the PR description is about.
- Where reasonable, find ways to split code changes out of feature / fix commits into refactor commits. Reading a diff top-down doesn't tell you anything; you need t
Read the rest
o jump around a lot to see how the parts interact. By splitting it up, you can more quickly understand each piece and the series of commits tells a story of how the feature of fix came to be.
- Commits are atomic while PRs tell a story, as long as it doesn't get too big. Refactor are usually leading towards a goal and having them tied together with that goal helps to provide the context to understand it all. However, this has to be balanced with the fact that larger reviews mean more things are missed on each pass and its different things on each pass, causing a lot of "20 rounds of feedback in and I just noticed this major problem".
As an example of these is a recent PR of mine against Cargo: https://github.com/rust-lang/cargo/pull/14239
In particular, the refactors leading up to the final change made it so the actual fix was a one line change. It also linked out to the prior refactors that I split out into separate PRs to keep this one smaller.
crates-io 0.32.0 (accidentally) downgraded and published again as 0.31.1? (2020)
1 points · Open discussionThanks; I get it. I was thinking maybe the open source community has discussed this in some detail. I'm not actively involved in any such discussions, but I did a quick look and found that "Documentation for cargo vendor use cases" [1] is a decent starting point to jump in. In that thread a user named 'rimutaka' has a comment titled "cargo vendor-related questions asked by the community" [2] of related conversations.
[1]: https://github.com/rust-lang/cargo/issues/7520
[2]: https://github.com/rust-lang/cargo/issues/7520#issuecomment-...
In Tech Debt: My Rust Library Is Now a CDONice hack! Would it have been possible back then to use cargo to pull in some dependencies?
The clean solution of cargo script is here: https://github.com/rust-lang/cargo/issues/12207
Following the links, the RFC contains a nice list of similar tools: https://rust-lang.github.io/rfcs/3424-cargo-script.html#prio...
In Scriptisto: "Shebang interpreter" that enables writing scripts in compiled langsYes, I am sure this is going to be a part of Rust 1.77.0 and it will release on 21st March. I say that because of the tag in the PR (https://github.com/rust-lang/cargo/pull/13257#event-11505613...).
I'm no expert on Rust compiler development, but my understanding is that all code that is merged into master is available on nightly. If they're not behind a feature flag (this one isn't), they'll be available in a full release within 12 weeks of being merged. Larger features that need a lot more testing remain behind feature flags. Once they are merged into master, they remain on nightly until they're sufficiently tested. The multi-threaded frontend (https://blog.rust-lang.org/2023/11/09/parallel-rustc.html) is an example of such a feature. It'll remain nightly only for several months.
Again, I'm not an expert. This is based on what I've obse
Read the rest
rved of Rust development.
I was curious about how an implementation for this would work and browsed the PR. Cool stuff, thanks for putting the effort in!
I noticed a very tiny typo which doesn't affect behaviour I think.
https://github.com/rust-lang/cargo/pull/13257/files#r1464506...
In Making Rust binaries smaller by default