I'd rather be able to update my dependencies automatically with a few commands instead of manually vendor all my dependencies, keeping up to date is really important for security. I get that game developers who only ever work on building single player games might have different opinions on "package managers", but they are in a very small niche.

One of the worst things working at companies shipping C++ was the myriad of meta-build systems that all tries to do dependency management as a part of the build system without having a separate concept of what a "package manager" is, this is truly the worst of both worlds, where people are happy to add dependencies, never update them, and never share code between projects and departments. I do not wish that way of working on my worst enemies.

Whatever problems package management brings is such a better problem to have than not having a package manager. That said I think everyone can get better at being more discriminatory of what they add to their project.

This article, although is trying to provide some arguments as for why package managers are "evil", I found the argumentation pretty weak/non-descriptive. It's good if you have the experiences that confirm a specific point of view, but I think these experiences need to be explained in some more detail, because people reading your article may have similar experiences and therefore would find it hard to agree with your points - just like me.

To give a concrete example, you said that javascript does not have a definition of a "package" in its langauge. But what does that really mean, and why should it lead to package manager managers? Because for me, a person who has worked with javascript just a little bit, I know package.json exists and most of the package managers I've worked with agree on what the contents of this file mean. If we limit our understanding to just npm, yarn and probably bun, we don't see how that causes or contributes to the dependency hell problem (sure it exists, but how?).

You said that Go mitigates the issue of dependency hell to some degree, but this is an interesting thought, give it more exploration! Why should something like Go not have this problem not be not as severe as in Javascript?

I may not remember the details of what you said in the article and I would like to check, but currently I can't access the site because it times-out for me.

I don't see the value in making it even harder to build software. I want to make things. Downloading a dependency manually and then cursing at the compiler because "it's right there! why won't it load!!" is just gonna make me want to build software less.

Anyone I want to work with on a project is going to have to have the same frustration and want to work on the project less. Only even more because you see they downloaded version 2.7.3-2 but the version I use is 2.7.3-1.

"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.

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.

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.

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

> People abuse cars and ram into crowds, so let's not have cars in our city!

> People abuse knives and stab people, so let's not have knives in our kitchen!

> People abuse package managers and create dependency hells, so let's not have package managers in our programming language!

No matter how you see it, this fits the definition of dumbing down;

Is this what you really want?

If that is the case, then we can shake hands and I will use a different programming language.

I don't know what the solution to this problem is, but I do remember a time (around 20 years ago) when this wasn't a big problem. Was working on a fairly large (each module between 50k - 100k LOC) C++ system. The process for using libraries:

1) Have problem that feels too complicated to hand-code.

2) Go on Internet/forums, find a library. The library is usually a small, flat collection of atomic functions.

3) A senior engineer vets the library and approves it for use.

4) Download the stable version: header file, and the lib file for our platform (on rare occasions, build it from source)

5) Place the .h file in the header path, and the lib file in the lib path; update the Makefile.

6) #include the header and call functions.

7) Update deployment scripts (bash script) to scp the lib file to target environment, or in some cases, use static linking.

8) Subscribe to a mailing list and very occasionally receive news of a breaking change that requires a rebuild.

This may sound like a lot of work, but somehow, it was a lot less stressful than dealing with NPM and node_modules today.

> Dependency hell [0] is a real thing which anyone who has worked on a large project has experienced. Projects having thousands, if not tens of thousands, of dependencies where you don’t know if they work properly, where are the bugs, you don’t how anything is being handled—it’s awful.

[0] https://en.wikipedia.org/wiki/Dependency_hell

I find it strange that they use a term with a common meaning, link to that meaning, and then talk about something else?

This article is a bit all over the map with discussions of high trust societies and their relation to language design and software dependency management.

That said I think the final takeaway is that systems that allow you to pin versions, vendor all those dependencies and resolve/reproduce the same file tree regardless of who's machine it's on (let's assume matching architectures for simplicity here) is the goal.

Note that removing 'manually' here, this still works:

> Copying and vendoring each package {manually}, and fixing the specific versions down is the most practical approach to keeping a code-base stable, reliable, and maintainable.

The article's emphasis on the manual aspect of management of dependencies is a bit of loss, as I don't particularly believe it _has to be manual_ in the sense of manually copying files from their origin into your file tree; that certainly is a real world option, but few (myself included) would take that monk-like path again. I left this exact situation in C land and would not consider going back unless adopting something like ninja.

What the OP is actually describing is a "good" package manager feature set and many (sadly not most/all) do support this exact feature set today

PS I did chuckle when they defined evil in terms of something that gets you to dependency hell faster. However, we shouldn't be advocating for committing the same sins of our fathers.

This reads much more like a critique of traditional open-source development than package managers themselves.

The author asserts that most open-source projects don't hit the quality standards so that their libraries can be just included, and they'll do what they say.

I assert that this is because there's no serious product effort behind most libraries (as in no dedicated QA/test/release cycle), no large commercial products use it (or if they do, either they do it in a very limited fashion, or just fork it).

Hobbyists do QA as long as it interests them/fits their usecase, but only the big vendors do bulletproof releases (which in the desktop realm seems to be only MS/Apple)

This might have to do with the domain the author chose - desktop development has unfortunately had the life sucked out of it with every dev either being a fullstack/cloud/ML/mobile dev, its mindshare and the resources going toward it have plummeted.

(I also have a sneaking suspicion the author might've encountered those bugs on desktop Linux, which, despite all the cheerleading (and policing negative opinions), is as much as a buggy mess as ever.

In my experience, it's quite likely to run into a bug that nobody has written about on the internet ever.

> "This is the automation of dependency hell. The problem is that not everything needs to be automated, especially hell. Dependency hell is a real thing which anyone who has worked on a large project has experienced. Projects having thousands, if not tens of thousands, of dependencies where you don’t know if they work properly, where are the bugs, you don’t how anything is being handled—it’s awful.

This the wrong thing to automate. You can do this manually, however it doesn’t stop you getting into hell, rather just slow you down, as you can put yourself into hell (in fact everyone puts themselves into hell voluntarily). The point is it makes you think how you get there, so if you have to download manually, you will start thinking “maybe I don’t want this” or “maybe I can do this instead”. And when you need to update packages, being manual forces you to be very careful."

I sympathise with this, but I have to respond that we have to live within existing ecosystems. Getting rid of npm and doing things manually won't make building SPAs have fewer dependencies, build would be incredibly slow and painful.

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.

The argument here is (in brief) "Package management is hell, package managers are evil. So let's handle the hell manually to feel the pain better".

And honestly speaking: It is plain stupid.

We can all agree that abusing package management with ~10000 of micro packages everywhere like npm/python/ruby does is completely unproductive and brings its own considerable maintenance burden and complexity.

But ignoring the dependency resolution problem entirely by saying "You do not need dependencies" is even dumber.

Not every person is working in an environment where shipping a giant blob executable built out of vendored static dependencies is even possible. This is a privilege of the Gamedev industry has and the author forgets a bit too easily it is domain specific.

Some of us works in environment where the final product is an agglomerate of >100 of components developed by >20 teams around the world. Versioned over ~50 git repositories. Often mixed with some proprietary libraries provided by third-party providers. Gluing, assembling and testing all of that is far beyond the "LOL, just stick to the SDL" mindset proposed here.

Some of us are developing libraries/frameworks that are used embedded in >50 products with other libraries with a hell of multiples combinations of compilers / ABI / platforms. This is not something you want to test nor support without automation.

Some of us have to maintain cathedrals that are constructed over decades of domain specific knowhow (Scientific simulators, solvers, Petrol prospection tools, financial frameworks, ... ) in multiple languages (Fortran, C, C++, Python, Lua, ...) that can not just be re-written in few weeks because "I tell you: dependencies sucks, Bro"

Managing all of that manually is just insane. And generally finishes with an home-made half-baked bunch of scripts that try to badly mimic the behavior of a proper package manager.

So no, there is no replacement for a proper package manager: Instead of hating the tool, just learn to use it.

Package manager are tools, and like every tool, they should be used Wisely and not as a Maslow's Hammer.

As I age, I do everything I can to avoid "one more dependency". There's a perverse nerd bragging effect that takes place where people equate their value as a programmer to how many dependencies they can name drop and mash up into their solution. It makes sense, since we evaluate each other, and the more dependencies you can reference in your workpast, the more stepping stones you've stepped on and therefor, been longer on the path.

Anymore, as I evaluate fellow programmers, I'm looking for whether they've discovered "one more dependency" is like signing up for "one more subscription you have to remember to pay for" and what they do to try and mitigate it.

I don't know if this is just coincidental but this was submitted at the same time as a large NPM malware sitution was exposed. https://news.ycombinator.com/item?id=45169657

Missed one of the biggest problems: Most assume the world is simpler than it really is. Not all the world is Rust, Python, Go, C++, or whatever language you advocate. I have millions of lines of C++, I'm interested in other languages, but they needs to interoperate with our C++. When we have a C++ library that does what you want I don't want you adding a new package to do the same thing as now we need to support both - sometimes will accept that using the package is the right answer, but often we need bug compatibility.

Not sure why this argument doesn't also apply to operating systems. Maybe everyone should be writing all their programs to run on a custom micro-kernel. Surely we can't trust other programmers to write something as complicated as an operating system.

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

> The problem is that not everything needs to be automated, especially hell.

What a great quote.

I'm very thankful for the Debian team's efforts to include most of my most commonly software packages in their repo. Out of all the differences between me and my colleagues workflows on MacOS and windows, this is the most impactful one. I don't remember the last time I had any kinds of dependency issues. I keep updating my packages when I log on and there are no version and/or dependency issues whatsoever.

> 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 popular), but because each package manager defines the concept of a package differently, it results in the need for a package manager manager.

This doesn't seem like a strong point to me. Yes, there are things like yarn, pnpm, etc. But IIUC practically all npm alternatives still define packages in the same way (a package.json at the root hosted by npmjs (or your private repo)), and the differences are ergonomic/performance related.

> [that each package manager defines the concept of a package differently] is why I am saying it is evil, as it will send you to hell quicker.

Then I think it's more of a language problem, not a problem with the concept of a package manager.

The post goes on to say that random packages are not necessarily better than what members of your team could make. At the end it gets to:

> Through manual dependency management. Regardless of the language, it is a very good idea that you know what you are depending on in your project. Copying and vendoring each package manually, and fixing the specific versions down is the most practical approach to keeping a code-base stable, reliable, and maintainable. Automated systems such as generic package managers hide the complexity and complications in a project which are much better not hidden away.

So that makes all of us human package managers. It's also true that you can get a package manager from internet folk that works better than the processes and utilities your team cobbles together to ease the burden.

I’ve had major Nissan Altima effect with this lately. A few weeks ago I set out to make a simple C and C++ package manager that just ignores dependency hell in favor of you explicitly specifying packages. And no binaries, just build from source and use Git as a backend for managing what source maps to what builds.

Plus Lua for package recipes. It’s going really well!

I don't find the argument very convincing. If anything you should have more time to carefully vet your dependencies when you don't need to spend time manually doing the tedious bit. Making things more difficult than they need to be just to introduce friction is a ridiculous proposition.

Package managers are constraint solvers. You could manually figure out if XYZ shared library works with somebody else's code, or, you could expect that they would label the range of shared library versions their code needs.

Note to self... don't use Odin.

I remember when a project failed on Kickstarter due to golang dependency hell in particular.

https://news.ycombinator.com/item?id=5796597

i had this idea for vendor based “package manager”

what if packages were meant to be read, and config was set inside the file directly

what if we transitioned to think of packages as templates, rather than generic black boxes

i think it would drastically reduce dependencies, package complexity, and improve understanding

> SDL3 might fix it all but the time to integrate SDL3 would be the same time I could write it from scratch.

The Programmers’ Credo: we do these things not because they are easy, but because we thought they were going to be easy

is sdl2 really that bad?

There are three points of prioritization here: you can use other peoples' code, manually vet all the code you're running, or accept that you need to trust a social network to vet stuff for you. Pick two. This is not a solvable problem.

EDIT: I've been rate limited, so the point is: unless you're Terry Davis, you're not going to be able to write software of any real complexity. Few people are going to even bother to vet the standard library, let alone the compiler, the runtime, etc etc.

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.