←back to thread

A critique of package managers

(www.gingerbill.org)
109 points gingerBill | 9 comments | 08 Sep 25 12:18 UTC | HN request time: 1.943s | source | bottom
Show context
NoboruWataya ◴[08 Sep 25 13:37 UTC] No.45168116[source]▶
I see this a lot with Rust where I will depend on one or two external crates for a simple application and then I am shocked to see dozens of dependencies being pulled in when I go to build. I actually think Cargo's support for feature gates and conditional compilation could in theory be a strong mitigation against this as crates can avoid pulling in dependencies unless you actually need a feature that relies on them, but in practice it doesn't seem to work that way as I often see these complaints about Rust.

I sympathise with the arguments but IMO laziness will always win out. If Rust didn't have Cargo to automate dependency hell, someone would create a third party script to fill the gap.

replies(3): >>45168261 #>>45168360 #>>45168912 #
1. jitl ◴[08 Sep 25 13:59 UTC] No.45168360[source]▶
Rust’s big issue here is the anemic standard library. I think overall the strategy makes some amount of sense; since there’s so much crazy alchemy like depending on nightly, no_std, etc in Rust, including stuff in std has more downside in Rust than in a language that’s more stable like Go.

But it’s annoying to have to deal with 3 different time libraries and 3 different error creation libraries and 2 regex libraries somehow in my dependency tree. Plus many packages named stuff like “anyhow” or “nom” or other nonsense words where you need to google for a while to figure out what a package is supposed to do. Makes auditing more difficult than if your library is named structured-errors or parser-combinator.

I don’t like go programming language but I do like go tooling & go ecosystem. I wish there was a Rust with Go Principles. Swift is kinda in the right ballpark, packages are typically named stuff that makes sense and Swift is closer to Rust perf and Rust safety than Go perf and Go safety. But Swift is a tiny ecosystem outside of stuff that depends on the Apple proprietary universe, and the actual APIs in packages can be very magical/clever. ¯\_(ツ)_/¯

replies(3): >>45169381 #>>45175495 #>>45180732 #
2. rich_sasha ◴[08 Sep 25 15:17 UTC] No.45169381[source]▶
I agree, though also I note Python has an extensive standard library and isn't much better in terms of package sprawl.
replies(1): >>45169718 #
3. jitl ◴[08 Sep 25 15:43 UTC] No.45169718[source]▶
Yeah, Python is a cautionary tale here, and I think one that informed the Rust stance.

Python is much older than Go, and has had more packages move from 3rd party into the stdlib to become a "battery", and then atrophy over the years while people move back to 3rd party alternatives with more features that are actually receiving maintenance. Eventually some of those modules were removed from core.

Perhaps the Go model only works when you have a very dedicated core group (for Go, mostly Google employees) around to continuously build and maintain the Cathedral of the standard library + toolchain together. Golang feels very much like UNIX (eg FreeBSD) for this reason, and Rust/Python more like Linux.

4. bigstrat2003 ◴[08 Sep 25 23:30 UTC] No.45175495[source]▶
The very sparse std is one of the few genuine mistakes I think Rust has made. I know the arguments for it, but I don't find them persuasive. A batteries included standard library, in my view, is just plain better and every modern language should have one.
replies(2): >>45176837 #>>45183773 #
5. forrestthewoods ◴[09 Sep 25 02:51 UTC] No.45176837[source]▶
Oh man I feel the opposite. Rust is an example where a sparse stdlib is clearly superior and better and more successful.

I mostly write C++ whose committee is incompetent and sniffs glue. And I deal a lot with Khronos committed who design pure garbage. “Design by Committee” is a pejorative for a reason.

6. curt15 ◴[09 Sep 25 11:59 UTC] No.45180732[source]▶
Just as the Rust community has largely converged on tokio as the standard async runtime, is there any reason why there couldn't exist a community-developed "batteries-included" standard library other than writing a standard library being a tedious and thankless task?
7. ModernMech ◴[09 Sep 25 15:52 UTC] No.45183773[source]▶
But what batteries to include? I'm sure your list of batteries is probably very different from mine, reflecting the difference in the work we both do. A lot of times when I hear a language has "batteries included", it's a bunch of features for web devs and nothing I would consider a "battery" for my projects.
replies(1): >>45184310 #
8. gingerBill ◴[09 Sep 25 16:24 UTC] No.45184310{3}[source]▶
What do you consider your set of "Batteries Include"?
replies(1): >>45185147 #
9. ModernMech ◴[09 Sep 25 17:15 UTC] No.45185147{4}[source]▶
Basically the stuff in here: https://www.ros.org