Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A critique of package managers

gingerbill.org

Post reply on HN
Print view View original

191–200 of 220 posts

Re: A critique of package managers

#191

Post by dismalaf »

tialaramex wrote: post #189
dismalaf wrote: post #168

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…

This seems like a loss of separation of concerns. As a result Odin's compiler is full of completely unrelated stuff because it takes on this far larger role supervising everything about a project not just being a compiler. Both Zig and Rust supply all of what you needed in the box, so all that Odin is doing here is commingling these features inside a single executable - there's no end user benefit that I can see.

?? Zig's compiler does way more, from automatically generating bindings to C files to including the entire C toolchain in its executable to running Zig build files (which allow you to do stuff like fetch files from the Internet) and being a compiler.

Odin's compiler does more than rustc or clang, about the same as javac and less than Zig or Go's executables.

Re: A critique of package managers

#192

Post by 1718627440 »

saulpw wrote: post #187
1718627440 wrote: post #148

Earlier quoted context omitted.

In C and C++ you don't need the transitive dependencies for compilation, you only need the header of the direct dependencies. As for linking they are only needed when linking dynamically, which was much less prevalent 20 years ago.

It's not about compilation, it's about interactions, and leaky abstractions.

This then means that the problem is more the quality of the library itself and not the package manager/dependency resolver/build system. You can have leaky abstractions just fine when all you do is add a single binary static library with nothing else going on.

Re: A critique of package managers

#193

Post by gnatmud8 »

flysand7 wrote: post #139

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…

package.json is a convention, not a language definition, hence package managers may implement "package" management differently; in reality conventions are followed, until they aren't, and that's where hell begins (if something can be abused - it will be); go and odin define package in the language itself as a folder containing source files, and they mitigate many management issues by just having a good standard library, so you wouldn't need as many packages to begin with;

Re: A critique of package managers

#194

Post by gnatmud8 »

greener_grass wrote: post #92
gingerBill wrote: post #72

Earlier quoted context omitted.

Nix isn't a solution to the problem of package managers. It just a better way to package management system, which thus makes it easier to go to dependency hell. So I'd argue it puts fuel on the flames. The solution is just to depend on less and manage them manually.

If we depend on less then we are capping what we can build to only what we can write and manually integrate. This is dis-empowering.

if you depend on more, you are capping what you can build to only what you can manage to get working and integrate, plus you also lose control over the code; for me personally, it's a lot easier to write a complicated algorithm, than it is to figure out a complex build system for a random library in the wild (with few exceptions like miniaudio); and it's especially worth it, because when i understand the problem, i can usually define a way better api for my usecase than any library writer can

Re: A critique of package managers

#195

Post by gnatmud8 »

MangoToupe wrote: post #106

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

if only people knew how easy it is to implement the standard library and make it way simpler than what is usually provided, everyone would be writing their own standard libraries; you can implement one with string manipulation, files, memory management, threading, and basic timing, in less than 1000loc of c code, as i have done before, and the biggest parts by far were console printing and filesystem stuff, and it's mostly because of windows utf-16 conversion nonsense

Re: A critique of package managers

#196

Post by 1718627440 »

account42 wrote: post #155
Macha wrote: post #131

Earlier quoted context omitted.

The package manager for C/C++ is apt, or rpm, or whatever package manager your system uses. These package managers were designed for the world of C/C++ software so it's less surprising that these languages haven't found as much of a push towards language package managers.

Yes, but that's quite different from how language package managers are used. A typical C/C++ project doesn't tell you to build it via apt/rpm instead you are expected to provide the dependencies using whatever means you choose or they are included in the repo. This means you don't need to fight a package manager to get fully offline or reproducible builds for example. RPM and APT packages are also usually not maintai…

Yes, C programs go to lengths to give the user choice. But it is recommended to use source packages for e.g. dpkg. And it's not too rare to have the .debian directory in the original VCS.

Re: A critique of package managers

#197

Post by ozim »

SideburnsOfDoom wrote: post #185
ozim wrote: post #163

Earlier quoted context omitted.

That's not package manager problem that's registry problem. NuGet is not having as many problems as NPM but also NPM is much more popular. NPM is also quite a wild west when it comes to publishing packages, any kid can make an account and publish 'left-pad' kind of crap. We already have quite safe and working setup with APT and software repositories for Debian, Ubuntu etc. While it is not so easy to publish your soft…

> That's not package manager problem that's registry problem I do not think that the two are cleanly separable. They are client and server ends of the same system. And I think my point is that I view it as more of a server (registry) and governance problem than the OP author does. Despite the fact that my employer also has an internal package feed, the security of nuget.org and the central public feed is intrinsic to…

Article is discussing „package manager” as generic concept.

My argument was that this concept is not the problem.

Problem is in governance of NPM while NuGet or Maven are stricter and therefore it is registry governance problem.

But on the other hand NPM is much more popular than any other registry.

Re: A critique of package managers

#198

Post by ozim »

1GZ0 wrote: post #12
smw wrote: 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.

The Author isn't arguing for not using third party dependencies. He's arguing for developers to be more conscious of the dependencies they use, by manually vetting and handling them. That screams "I've been down the package manager route and paid the price". Not inexperience.

I disagree with this take. There should be just more governance on the registry side of things.

For NuGet or Maven I think dependency hell is not something you run into and I don’t have package manager manager for those languages.

There should be enough trust just like I can do sudo apt install.

His take screams „I want to push my niche approach and promote my language from my Ivory Tower of language creator”. He still might not have any relevant experience building businesses line software just like O don’t have experience with building compilers or languages.

Re: A critique of package managers

#199

Post by wannadingo »

ModernMech wrote: post #183
1GZ0 wrote: post #170

Earlier quoted context omitted.

Its not clickbait though. You should try reading the article before passing judgement. Its not like the article is called "5 facts that will make you hate package managers. Number 5 will shock you"

It was clickbait because the article, which I did read, did not support the contention that package managers are evil . Therefore "evil" seems to be used in a hyperbolic way to grab attention, which makes it clickbait, specifically ragebait.

Then again, there is a trope going back to Knuth - "Premature optimization is the root of all evil" - which is an argument that it is not clickbait, but merely applying a pattern in discussions about computer programming.

Re: A critique of package managers

#200

Post by Defletter »

wannadingo wrote: post #199
ModernMech wrote: post #183

Earlier quoted context omitted.

It was clickbait because the article, which I did read, did not support the contention that package managers are evil . Therefore "evil" seems to be used in a hyperbolic way to grab attention, which makes it clickbait, specifically ragebait.

Then again, there is a trope going back to Knuth - "Premature optimization is the root of all evil" - which is an argument that it is not clickbait, but merely applying a pattern in discussions about computer programming.

Hyperbole is just a pretty common thing for humans to do
Post reply on HN