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:56:55 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 sourcesTHthristian·Dec 22, 2014
In the current scenario, where the definition of 'Rust' changes on a daily basis, that's a major pain-point, but once Rust hits 1.0 then all future changes will be backwards-compatible (until version 2.0, in the distant future if ever), so it should be much less of an issue.
That said, it's definitely a thing the Cargo devs are thinking about: https://github.com/rust-lang/cargo/issues/1044
https://github.com/rust-lang/cargo/issues/837
In Rust, an Anti-Sloppy Programming LanguageTo be fair, it's not possible to tell cargo to do that (yet) (refering to https://github.com/rust-lang/cargo/issues/60 )
In Rust 1.0: Scheduling the trainsI would agree with adding some <noscript> tags to at least print a message telling you to turn it back on, sure. Filed: https://github.com/rust-lang/cargo/issues/931
In The Rust community's crate hostYou're going to want to subscribe to https://github.com/rust-lang/cargo/issues/925 then :)
In The Rust community's crate hostCommand-line search would be cool, for sure. Submitted! https://github.com/rust-lang/cargo/issues/925
In The Rust community's crate host> Rust probably has similar tools
* Testing
Built-in: http://doc.rust-lang.org/master/guide-testing.html
* Documentation
Built-in: http://doc.rust-lang.org/master/rustdoc.html
* Sharing code and specifying dependencies
The newly released 'cargo': http://crates.io/ https://github.com/rust-lang/cargo/ (alpha, but quickly improving). This will be Rust's cabal equivalent, almost certainly with support for generating documentation and cross-compiling (it already has basic support for running the tests described above).
* Formatting
Missing at the moment, but very wanted: https://github.com/rust-lang/rust/issues/3195 .
(Well, to be precise, the compiler has the '--pretty normal' option, but it's not so good. https://github.com/pcwalton/rustfmt is the work-in-progress replacement.)
* Cross compiling
Already supported, although it requires manual
Read the rest
ly compiling Rust with the appropriate --target flag passed to ./configure, to cross-compile the standard library.
> which is to use the rustdoc tool to export the projects documentation as json.
Side note: it already does this by defaut: http://doc.rust-lang.org/search-index.js
I'm not sure if that's enough information to do this analysis, but the basics are there! I've opened an issue: https://github.com/rust-lang/cargo/issues/47
In Cargo, Rust's Package Manager> If it's not going to change, then maybe some outreach should be done to get him to tag it 1.0.
Absolutely. Let me make an issue about that: https://github.com/rust-lang/cargo/issues/46 If he doesn't respond, I will email him.
> As for the FUDdiness...
Thanks! Since the points are enumerated, I can refute them:
> * You can't override a dependency:
You can, in modern Bundlers. But the transitive dependency issue is inherent to Ruby, not Bundler. Cargo will work like npm in this regard, not like bundler.
> Dependencies can disappear on you:
The central repository isn't built yet, but this is very valid. The reason that `gem yank` is still available to everyone is that you'd be surprised how often people push proprietary stuff up to RubyGems. It was removed for a while and caused a significant burden on the RubyGems team.
Regardless, yes, t
Read the rest
his is a serious consideration.
> It has weird rules:
Totally fair. Let's learn from that and make Cargo not have weird rules. :)
> * It promotes bad practices:
Yup, that's a Rails thing. Rust should be way better, as it doesn't have this kind of issue.
> * It's slow:
This actually has just as much to do with RubyGems as it does Bundler. See all of the presentations Andre has been doing recently, and the bundler-api project.
> * It was designed for MRI:
Quite fair. We only have one Rust implementation so far, but `cargo exec` won't be necessary.
------------------------
> So, it should be met with some level of scrutiny.
Absolutely! I don't mean to say "just take this without complaints." But without specific, actionable complaints, it won't get fixed. Please make as many specific, actionable complaints as possible, especially now, pre 1.0.
There are actually already MULTIPLE parsers for TOML in Rust, and Cargo switched between the two yesterday.
As you say, this is a testament to TOML's simplicity.
EDIT: Furthermore, TOML is going to have a 1.0 soon: https://github.com/rust-lang/cargo/issues/46
In Cargo, Rust's Package ManagerYes, the developers are actually domain experts being paid by Mozilla. The release of this website also coincided with the move of the source repository into the rust-lang organisation: https://github.com/rust-lang/cargo .
In Cargo, Rust's Package ManagerError handling in Rust is actually pretty awesome. There's a standard `Result<T, E>` type. One can write a potentially fail-able function like:
fn can_fail(arg: bool) -> Result<(), StrBuf> {
if arg {
Ok(())
} else {
Err(StrBuf::from_str("Oops! Something went wrong."))
}
}
Here, there's no value when the function succeeds `()`. When it fails (I don't mean fail as in a `fail!()` or a panic or anything), you get a string back.
You can pattern match the return value:
match can_fail(true) {
Ok(_) => {},
Err(err) => {}
}
This can get quite cumbersome, however. That's why there's a `try!` macro that adds composability. The idea is that if you have a function returning a `Result`, wherever that function is being called could also return a `Result`.
fn higher_up
Read the rest
() -> Result<(), StrBuf> {
try!(can_fail(true));
}
`try!` is simply:
match $e { Ok(e) => e, Err(e) => return Err(e) }
This allows error to propagate up the chain.
When you're working in big-ish projects, it'd be best to have something better than a simple `StrBuf` for an error. You'd probably want a struct:
pub struct LibError {
message: StrBuf,
error: Error
}
pub enum Error {
One,
Two,
Three
}
Where `Lib` is the library/project name.
You can then create a new result type based on your new error type:
type LibResult<T> = Result<T, LibError>;
Then you can use `LibResult<T>` everywhere in your app.
You can view this example done in a few of my own libraries (https://github.com/TheHydroImpulse/gossip.rs/blob/master/src...) and cargo (https://github.com/carlhuda/cargo/blob/master/src/cargo/util...).
That's a simple overview of it. Error handling is super simple, not verbose (thanks to try!) and in your control. Because of Rust's type system, things like `Result<T, E>` is available and are so much better than simple return values (like integers: -1 vs 0 uhhh)
They already started to write some code: https://github.com/carlhuda/cargo
In Announcing the new Rust package manager, Cargo