Live data from Hacker News

A critique of package managers

gingerbill.org

31–40 of 220 posts

Re: A critique of package managers

#31
post #16
post #10

Earlier quoted context omitted.

Inexperience of an author who develops quite successful programming language for like 10 years? Quite a bold statement. Actually his perspective is quite reasonable. Go is in the other part of the spectrum than languages encouraging "left-pad"-type of libraries, and this is a good thing.

I've seen plenty of intelligent people acting pretty stupid. As my psychology professor used to say. "Smart is how efficiently use your intelligence. Or don't." So someone pretty low IQ can be smart - Forrest Gump. Or someone high IQ can be dumb occasionally - a professor so very attuned to his research topic at expense of everything else.

How is this relating to the alleged inexperience of the original author? Not sure what do you mean.

Re: A critique of package managers

#32
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.

Re: A critique of package managers

#33
I wouldn't say I'm a dependency maximalist but it not far off.

Yes, shared code has costs

- more general than you likely need, affecting complexity, compile times, etc

- comes with risks for today (code) and the future (governace)

But the benefits are big. My theory for one of the causes for Rust having so many good cli's is Cargo because it keeps the friction low for pulling in high quality building blocks so you can better focus on your actual problem.

Instead of resisting dependencies, I think it would be better to spend time finding ways to mitigate the costs, e.g.

- I'd love for crates.io to integrate diff.rs, provenance reporting (https://lawngno.me/blog/2024/06/10/divine-provenance.html), etc

- More direct support for security checking in cargo

- Integrating cargo-vet and/or cargo-crev into cargo

Re: A critique of package managers

#34
In general, I think the dependency hate is overblown. People hear about problems with dependencies because dependencies are usually open source code used by a lot of people so it is public and relevant. You don't hear as much about problems in the random code of one particular company unless it ends up in a high profile leak. For example, something like the heartbleed bug was a huge deal and got a lot of press, but imagine how many issues we would be in if everyone was implementing their own SSL. Programmers often don't follow best practices when they do things on their own. That is how you end up with things like SQL injection attacks in 2025.

Dependencies do suck but it is because managing a lot of complicated code sucks. You need some way to find issues over time and keep things up to date. Dependencies and package managers at least offer us a path to deal with problems. If you are managing your own dependencies, which I imagine would mean vendoring, then you aren't going to keep these dependencies up to date. You aren't going to find out about exploits in the dependencies and apply them.

Re: A critique of package managers

#35
> How do I manage my code without a “package manager”? [...] Through manual dependency management.

Slackware Linux does precisely that.

I'm a Slackware user. Slackware does have a package manager that can install or remove packages, and even a frontend that can use repositories (slackpkg), but it does have manual dependency resolution. Sure, there are 3rd-party managers that can add dependency resolution, but they do not come with the distro as default.

This is a very personal opinion, but manual dependency management is a feature. Back in the day, I remember installing Mandrake Linux 9.2 and activating the (then new-ish) framebuffer console. The distro folks had no better idea than to force a background "9.2" image on framebuffer consoles, which I hated. I finally found the package responsible for that. Removing it with urpmi, however, meant removing all the graphical desktop components (including X11) because that stupid package was listed as a dependency of everything graphical.

That prompted me to seek alternatives to Mandrake and ended up using Slackware. Its simplicity had the added bonus of offering manual dependency resolution.

Re: A critique of package managers

#36
post #5

"When using Go for example, you don’t need any third-party libraries to make a web server, Go has it all there and you are done." Fine, now what if you need to connect to a database, or parse a PDF, or talk to a grpc backend. What a hilariously short-sighted example. To me, this whole article just screams inexperience.

I think the argument presented, is that whatever a Go package does, it does well.

Btw the Js ecosystem also has quite a few good packages (and a ton of terrible ones, including some which everyone seems to consider as the gold standard).

Re: A critique of package managers

#37
post #15

> Each dependency is a potential liability. I mean, sure. So what does the solution look like? From my perspective it looks like a tool that is able to update your dependencies so that you can easily pick up bug fixes in your dependencies, which sounds an awful lot like a package manager. > JavaScript is great example of this as there are multiple different package managers for the language (npm being one of the most…

> t looks like a tool that is able to update your dependencies so that you can easily pick up bug fixes in your dependencies, which sounds an awful lot like a package manager. If only it where that easy. Often the update isn't source compatible with the package that uses it so you can't update. There are some projects I use that I can't update because I use 6 different plugins, and each updates to the main project on…

I agree with all of the problems that you're highlighting, but would say that all of those problems exist whether or you're doing manual dependency management or using a package manager.

The solution IMO (which is non-existent afaik) would be to integrate some kind of third party auditing service into package managers. For example, for your npm project you could add something like this to your package.json:

` "requireAuditors": [ { "name": "microsoft-scanning-service", "url": "https://npmscanner.microsoft.com/scanner/", "api_key": "yourkeyhere, default to getting it from .env" } ] `

And when you npm install, the version / hash is posted to all of your required auditor's urls. npm should refuse to install any version that hasn't been audited. You can have multiple auditing services defined, maybe some of them paid/able to scan your own internal packages, etc.

I've thought about building a PoC of this myself a couple of times because it's very much on my mind, but haven't spent any time on it and am not really positioned to advocate for such a service.

Re: A critique of package managers

#38
Honestly, he's not wrong. I use Ruby and 99% of the gems on rubygems.org are absolute trash. I use Rails and stuff like Nokogiri or Faraday, also RubyLLM, but little else because of reasons.

NPM is even worse, you import one thing and get 1000s of trash libraries so nowadays the only JS I write is vanilla and I import ES Modules manually.

Also, Odin doesn't make adding dependencies that difficult, you can literally just throw an Odin library into your project as a folder and it's available. The Odin compiler does everything else for you.

Re: A critique of package managers

#39
post #17

Earlier quoted context omitted.

But titled the post "package managers are evil"

> The term “evil” is being used partially hyperbolic to make a point. Kind of bonkers this even needs to be said, and even then it's missed/ignored.

The title is provocative and attention grabbing. -- It's completely fair game to react to the provocation rather than the substance of the article itself. (Or, rather, it's silly to use attention grabbing rhetoric, then complain that people paid attention to the rhetoric).

I'd prefer instead a more balanced title like "Remember to Consider the Costs When Using Package Managers", or whatever.

Re: A critique of package managers

#40
There's a fair bit of semantic quibbling here.

Regardless of how they define these terms, producing a list of hashes which function as a commitment to specific versions of dependencies is a technique essential to modern software development. Whatever the tools are called, and whatever they do, they need to spit out a list of hashes that can be checked into version control.

You could just use git submodules, but in practice there are better user experiences provided by language package managers (`go mod` works great).

A good amount of this ranting can probably be attributed to projects and communities that aren't even playing the list of hashes game. They are resolving or upgrading dependencies in CI or at runtime or something crazy like that.

Post reply on HN