Live data from Hacker News

A critique of package managers

gingerbill.org

171–180 of 220 posts

Re: A critique of package managers

#171

Earlier quoted context omitted.

If that's what happens, I think in the following claim: > Odin's compiler knows what a package is and will compile it into your program automatically. ...the word "automatically" should be dropped. Of course compilers compile any supplied dependency "automatically", but it is so obvious that we don't often use the adverb just for that.

> Of course compilers compile any supplied dependency "automatically", but it is so obvious that we don't often use the adverb just for that. They often don't though. Rust, C, C++ need either long command line invocations or a build system for anything beyond hello world. Zig needs a build file for anything beyond hello world. With Odin, you just invoke "odin build ." and all your dependencies are taken in without ne…

We call that a build system. It is not like that there is no build system; you have an integrated build system that is optimized for typical situations. Which is great by its own, but other languages and toolings would have optimized other metrics (for example, you can't ignore Cargo when talking about Rust's build system) so it is not a fair comparison.

Re: A critique of package managers

#172

Earlier quoted context omitted.

Not everything in the world revolves around Linux. Distros terrible choices around shared library architecture has nothing to do with build systems for most languages.

True. The most popular Unix is after all macOS, followed shortly by WSL2

There are way more servers running linux than there are macos installs. And wsl2 is linux.

Re: A critique of package managers

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

Re: A critique of package managers

#174

> 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 h…

> My general view is that package managers (and not the things I made distinctions about) are probably in general a net-negative for the entire programming landscape, and should be avoided if possible.

I am arguing that their "benefits" are only very short-term, if there is actually benefit for them in the first place. The strawman that you present has been repeated already and is not considering that all of those other things are actually useful and good alternatives.

Re: A critique of package managers

#175

Earlier quoted context omitted.

> Of course compilers compile any supplied dependency "automatically", but it is so obvious that we don't often use the adverb just for that. They often don't though. Rust, C, C++ need either long command line invocations or a build system for anything beyond hello world. Zig needs a build file for anything beyond hello world. With Odin, you just invoke "odin build ." and all your dependencies are taken in without ne…

We call that a build system. It is not like that there is no build system; you have an integrated build system that is optimized for typical situations. Which is great by its own, but other languages and toolings would have optimized other metrics (for example, you can't ignore Cargo when talking about Rust's build system) so it is not a fair comparison.

It is a build system in the technical sense but it's hard to explain to people because they expect it to be separate from the language entirely. If I said Odin had a build system, they'd be expecting an external build script. And when you say you don't need that, they usually get really confused.

So how do you explain such a system to someone? This is a genuine question I am not sure how to answer.

Re: A critique of package managers

#176

Earlier quoted context omitted.

> Of course compilers compile any supplied dependency "automatically", but it is so obvious that we don't often use the adverb just for that. They often don't though. Rust, C, C++ need either long command line invocations or a build system for anything beyond hello world. Zig needs a build file for anything beyond hello world. With Odin, you just invoke "odin build ." and all your dependencies are taken in without ne…

We call that a build system. It is not like that there is no build system; you have an integrated build system that is optimized for typical situations. Which is great by its own, but other languages and toolings would have optimized other metrics (for example, you can't ignore Cargo when talking about Rust's build system) so it is not a fair comparison.

I mean, is a "build system" even real? Or does it just exist because of a shortcoming with a compiler? All "compilers" have multiple steps usually invoking other programs at some point: parsing, actual code transformation, linking, etc..., some also find packages, some rely on an external tool or long command line invocations.

But yes, Odin builds it into their compiler. Rust doesn't but does have Cargo. Both are easy, as far as typical usage goes. Rust automates dependency management, Odin doesn't automate it per se but does make it easy. Which is what the whole discussion is about. A bunch of HNers whining that Odin makes it too hard, even though everyone sane uses Git anyway, and you can add dependencies using Git, and Odin will compile them without a build tool.

So for a Rust project you use Cargo + Git, for an Odin project you use Odin + Git, for a C/C++ project you use Meson (or something else if you hate life) + Git. In the end it's mostly the same, Bill just doesn't seem to want to deal with an NPM or Crates.io situation (and fair enough!).

Re: A critique of package managers

#177

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

Completely coincidental. I wrote the article before the situation, AND the article is a transcription of a video recorded in July.

Re: A critique of package managers

#178

> 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 h…

> My general view is that package managers (and not the things I made distinctions about) are probably in general a net-negative for the entire programming landscape, and should be avoided if possible. I am arguing that their "benefits" are only very short-term, if there is actually benefit for them in the first place. The strawman that you present has been repeated already and is not considering that all of those ot…

The obvious benefit to me are the automations, I have directly experienced these time benefits

I read you think these automations lead to more harm than good so are a net negative, and I understand that point of view

However, I think this is not a tautology

I think dependency hells and bad dependencies absolutely happen indeed, but are conditioned to badly managed programming projects

And I do not want to suffer from the dumbing down of stripping out package managers

Re: A critique of package managers

#179

Earlier quoted context omitted.

> My general view is that package managers (and not the things I made distinctions about) are probably in general a net-negative for the entire programming landscape, and should be avoided if possible. I am arguing that their "benefits" are only very short-term, if there is actually benefit for them in the first place. The strawman that you present has been repeated already and is not considering that all of those ot…

The obvious benefit to me are the automations, I have directly experienced these time benefits I read you think these automations lead to more harm than good so are a net negative, and I understand that point of view However, I think this is not a tautology I think dependency hells and bad dependencies absolutely happen indeed, but are conditioned to badly managed programming projects And I do not want to suffer from…

Choose your own hell then. I'm not going to stop you.

And no, it's not a tautology, it's an empirical observation.

And as I said, not everything ought to be automated, especially hell.

Re: A critique of package managers

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

Post reply on HN