Hacker News Reader

Comment by smw | Hacker News Reader

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

View on HN

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.

> He's arguing for developers to be more conscious of the dependencies they use

"be careful all the time" doesn't scale. Half of all developers have below-average diligence, and that's a low bar. No-one is always vigilant, don't think that you're immune to human error.

No, you need tooling, automation to assist. It needs to be supported at the package manager side. Managing a site where many files are uploaded, and then downloaded many times is not a trivial undertaking. It comes with oversight responsibilities. If it's video you have to check for CSAM. If it's executable code, then you have to check for malware.

Package managers are not evil, but they are a tempting target and need to be secured. This can't just be an individual consumer responsibility.

I can't speak for other ecosystems, but some NuGet measures are here:

https://devblogs.microsoft.com/dotnet/building-a-safer-futur...

https://learn.microsoft.com/en-us/nuget/concepts/security-be...

I believe that there have been (a few) successful compromises of packages in NuGet, and that these have been mitigated. I don't know how intense the arms race is now.

> "be careful all the time" doesn't scale

Yes, this is the C attitude, where you provide no safety rails or poka-yokes or, indeed, package managers, and therefore you get a lot of fragile reimplementations of package managers (autoconf, anyone?). But you get to keep the satisfaction of blaming the users.

nuget is pretty good. It helps that packages tend to be substantial things, not left-pad.

> autoconf, anyone?

GNU Autoconf isn't a package manager, it's more an analogue to a setup executable on MS Windows, to detect where the user wants stuff to be installed, where the user has stuff already installed and which features the user wants.

> It helps that packages tend to be substantial things, not left-pad.

Agree, this is IMHO also a better pattern. 1-liners or even 20-liners are not worth the overhead of extracting a package. Or of depending on a package.

"Half of all developers have below-average diligence" - a lot of this is also not developer choice, but environmental. So much software is developed and maintained in very constrained economic environments, often by solo devs who also have other responsibilities. The choice here often is trading some "diligence" for "meeting business requirements in the time / budget constraints" imposed by your employer.

Absolutely true, but still indicates the need for tooling, for automation, and for oversight at the the package store.

"developers, be more conscious" isn't going to fix all the issues. In general, there are not individual effort fixes to systemic issues.

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 software to Debian, you get dedicated maintainer and all kinds of requirements you have to fulfill.

But this way all the issues with trust are if not mitigated, they are minimized and for example XZ Utils hack didn't make it to production systems and it took 3 years to prepare and pull it off.

> 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 the security of the whole system.

Nuget was closer to the NPM end of the spectrum, but has tightened up considerably over time. Particularly the "Package ID Prefix Reservations" feature tells me that package names that start with certain words are owned by the relevant entity, be it "System." or "Azure." from Microsoft, or "AWS" from Amazon.

This is important as it's used to distribute SDKs and optional but standard library components and updates.

There is certainly junk on there, but not much load-bearing junk.

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.

> Article is discussing „package manager” as generic concept. My argument was that this concept is not the problem. Problem is in governance of NPM

Then we're in agreement that the article's author has the wrong end of the stick, by focusing on the client end of the file transfer connection.

Huh? I am not saying the repositories have (or should have) no responsibility, but you are also responsible for your own actions.

The popularity of such repositories and package managers are due to users of them.

And the concepts are trivially separable in my opinion. A package manager uses a repo of packages to download from. You don't need a package manager to use a repo. And a package manager could be just local to your machine and thus not need an external repo either. I know in practice the two are combined but that doesn't mean they are not distinct concepts.

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.

> It's completely fair game to react to the provocation rather than the substance of the article itself.

Yeah, but its down right stupid to do so.

The title isn't even misleading or part of a Motte-and-bailey argument.

People just hear "Package Managers are Evil" and assume that the author means you shouldn't use third party dependencies. Which is NOT what's being argued.

But I guess you'd know that, if you read passed the title.

In the article, the author does say "I am not advocating to write things from scratch", while also describing third party dependencies as liabilities (e.g. security vulnerabilities), that people are too trusting of third party dependencies, that people overestimate the quality of third party dependencies.

I think you're splitting hairs if you're saying that these points from the article argue against package managers but don't argue against using third party dependencies.

I similarly think you're splitting hairs if to consider "package managers are useful?" and "third party dependencies are useful?" as distinct points.

Liability: "Something for which one is liable; an obligation, responsibility, or debt."

Third party dependencies absolutely are liabilities. You are liable to vet them, inspect their licenses and keep them updated while ensuring that they continue working with your existing code.

This is not something package managers help you do. Package managers like NPM make it trivial to skip these steps entirely.

What is being argued for, is a more thoughtful approach to handling third party dependencies. Or at the very least, the need for people to realise that there are costs associated with bringing third party dependencies into your codebase.

Its not splitting hairs at all. Its more of an presumption on the part of a large number of readers, that the 2 points argued conflate to "Package manager suck, because third party dependencies suck and you should write everything from scratch instead".

Sorry but I lack any respect for authors that use clickbaits. Call them put and move on seem the best approach.

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.

I wouldn't class it as clickbait myself, but I will stand by the use of the word "evil". I am using evil in the very old fashioned sense: the privation of the good. Is the title provocative? Yes. But that's the point of the article in general. I am trying to argue that they are a net bad with virtually no good upsides to them for the programming world as a whole. They've automated something at scale which should not have been automated. And to be clear, there is no solution to the problems they are trying to solve, rather it's all about trade-offs.

I a little annoyed that HackerNews post renamed it to "A critique of package managers" because that implies very different connotations. I'd view an article written like that as if I have some criticisms that could be addressed, rather than the entire concept being bad from the start.

> I am trying to argue that they are a net bad with virtually no good upsides to them for the programming world as a whole.

What I'm saying is that you have failed in this argument. You hardly even attempt to make it. Thus clickbait.

You said "this is why I am saying it is evil, as it will send you to hell quicker."

Okay, so then it's up to you to prove this hell actually exists. But you don't. You just assert its existence -- "Dependency hell is a real thing which anyone who has worked on a large project has experienced." By framing it this way, you can dismiss anyone who claims to not have experienced this as not having sufficient experience. But reading the comments here, a lot of people have experienced a sort of "dependency hell" (the kind that's talked about in the wiki you link to) that is solved by package managers.

So that's why it's classed as clickbait -- you (admittedly) wrote a provocative headline that you don't even remotely back up.

FYI for the future since you're lamenting in many comments that people are misinterpreting you, this is why. Given that you don't really make an attempt to prove this dependency hell and package managers are evil, and you don't acknowledge anything good about them, it's reasonable to assume your bias is just that dependencies are evil at their core. It's actually the most charitable reading because otherwise you seem confused.

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

> The title is provocative and attention grabbing. -- It's completely fair game to react to the provocation rather than the substance

No it isn't.

The title of the article comes from the direct words I said in the video, of which the article is effectively a polished transcription of.

Your "more balanced title" isn't even close to what I am saying. I am saying that Package Managers are just bad and should not be used. Not "remember to consider the costs". The net cost is bad for everyone, that's why I said "evil".

I guess clickbait is evil

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.

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.

Not to mention we've have had decades of software development without automated package managers and people did just fine.

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.

The above comment is merely pointing out that a 10y+ experienced language designer can still have naive viewpoints on application development. Anyone who's built a non-trivial userspace application knows that realistically you'll have to reach outside a particular languages standard library in most cases to provide value without reinventing wheels.

In other words: when someone's knowledge is disproportionately localized/siloed to their prospective subfield or domain of expertise, it does not necessitate generalization to others.

I'm certainly not saying this is the case with this particular individual, as I'm personally not familiar with their background. I'm simply stating that it's a plausible explanation for when experts in one domain make naive assertions about another domain they might not have the same experience in.

I don't buy it.

A guy designing and then implementing a programming language has a much bigger chance to put a lot of rational thinking into the tooling like dependency manager, than a typical language consumer, who can and often is easily falling into the languages emo wars.

As the original article points out, not all languages come out of the box with a sane/rationally designed dependency manager. I can think of only a handful in that category. The vast majority of languages fall short and rely on secondary community projects to prop up the dependency management for the language: maven, gradle, npm, pip/pypi, now uv, etc.

Language designers in general terms will fall into the "more knowledgeable than the average developer"category , but let's not pretend they're anything but mere mortals like the rest of us.

NGL Ive somehow lost the thread and can't tell if we're talking about language integrated dependency managers in the abstract (in the OP), or specifically speaking about golang, odin or something else. I don't know what the emo wars are specifically in reference to but I think we jumped the shark here.

Put another way: what makes this time different? How does this designer's proclivity and push towards X learn from our collective past mistakes; what does it bring to the table?

Yes dependency hell is "bad", but we have several language and package management systems today from ninja to uv that make various, obvious trade offs. Optimizing developer time, ergonomics, reproducible builds, configuration complexity are just some of the axes these pre-existing systems focus on.

If you're extremely lucky you get to pick a system that aligns with your style of work and ideals for how software should be built. If you're not, and like the rest of us, you get stuck with everyone else's poor decisions and are forced to make do. All code is legacy code given the right time horizon, so think about software with all those manual dependencies included on disk and nowhere else. How do you safely apply those required security fixes, etc. Don't be user hostile, this will just lead to our past sins like the C of old.

From a purist perspective, you can forgo all other software that you have not written in-house / or does not come with the standard library. This is the monk approach, but outside a few niche work environments that's untenable.

> than a typical language consumer, who can and often is easily falling into the languages emo wars.

How is ginger bill excluded from this group? No one is more invested in a language than its creator(s).

Sure, he might have given it a lot of thought, but he came up with some completely bonkers conclusions. If you don't want dependencies, DON'T IMPORT DEPENDENCIES. Don't make your dependencies extremely hard to add.

Yeah when speaking about emotions: the amount of emo reactions here, including shouting with all caps, lets me think we've fallen into the old story: the author kind-of praised Go, but it's unfashionable here; the contrary, the fad here is to hate Go, so the author needed to get his hate. As simple as that. The rest is just trying to hide the hate under seemingly rational arguments.

Yawn.. saw it before...next, please

Yeah, god forbid you use bolding to emphasize your phrase on this site. It's considered emotinal response, but yours is purely logical?

I'm glad you saw through me like a Superman through a lead book. Which is to say, not at all. I wasn't even thinking of Go. Where did this come from? I never mentioned Go. I don't use it or know how it does its packaging.

Are you projecting your feelings onto me as a sort of substitute for the HN gestalt? The discussion was about package managers being evil.

Now please return to the topic at hand.

Let's say you have NPM package manager. What prevents you a rational individual from saying:

      {
         "depedencies": {}
      }

You did not had Go in mind, but the [original commenter](https://news.ycombinator.com/item?id=45167394#45168550) apparently did as he has quoted exactly the line about Go. Then you (and me) commented under that comment.

So my snarky remark was about him, not about you. I think it's ok to rewind the tree up to see what is about whom. I can sincerely apologize that I have put replies to two distinct human beings, you and that other commenter, in one paragraph. Honestly, I can see that could let to confusion.

I think we can stop now..

I have? Pray tell.

Have what? Heavily invested in language you're building? I think that's a given.

Not clear-headed about this? https://old.reddit.com/r/programming/comments/1nbkwzt/packag...

    > gingerbill[S] 1 point 2 hours ago
    >  So a tool that enables evil is not an evil tool?

See counterpoint: hammers, freezers, cars, arrows, guns, bombs, planes, etc. Each of them *can* enable evil. Same way a package manager *can* enable sprawling dependency list.

You see you just completely missed my replies to that too.

> Let's put it this way, what does a package manager specifically (not the other distinctions I make in the article) do (other than enable bad laziness and lack of proper vetting) that is actually good?

https://old.reddit.com/r/programming/comments/1nbkwzt/packag...

And you missed the retort to that reply as well. It's a force multiplier and a time saver. Same as with any tool.

And to reply to your next post:

     > Getting to hell quicker is not a good thing. "Emerge on the other side quickly", the other side is still hell, you haven't emerged out of it.

Remaining stuck in limbo forever is worse than going to hell faster :) At least in hell you have a decent company.

I'd rather use a hammer even if there is a higher chance to smack my fingers than to have to hit a nail repeatedely with my head.

Thank you?

Is it "quite successful"? How would I distinguish such a "quite successful" language from say Hare or V or are these all "successful" in your mind?

I know very few people using Hare, especially since it only works on "FOSS platforms". And I will still maintain that V is vapourware. They still have the same false claims on the website that they've had from the beginning for ~6 years.

Odin is "successful enough" so far. Also, you know about it, so that says something.

I know about Hare and V too, so, then what exactly does it say for me to know about a programming language? Not much.

I have technically written more Odin than Hare (one Godbolt example, arguably two if you count my explaining how to modify the example to illustrate another problem) but that just means I have more justification to say I don't like it.

I've written a lot more Scheme and I had so thoroughly forgotten writing Scheme that I had to go read the source for myself when I got email about it decades later to be sure it wasn't just a coincidence of author names.

I'm not convinced there is space for any of the "C successor" languages in the twenty-first century and in the event space is made or given for one I doubt there'll somehow be room for more. So with today's field I would bet on Zig.

Odin is not trying to be a "C successor" rather as the website states: "Odin is the C alternative for the Joy of Programming".

And there doesn't have to be "one winner". This isn't Highlander. It is just wonderful that there is now choice in this domain beyond just the old and obvious.

There's commercial software produced in Odin that has made money. Not sure the same can be said of Hare or V.

Why the need for distinguishing and an urge for comparison? We're talking about Odin, that's it. As a project that (as I understand) didn't have any big corp investment, it's impressive.

The claim was that we should assume Odin's author is experienced because he wrote a successful language. If we've decided it doesn't matter whether it's successful then the claim was entirely circular. Yes, the creator of Odin is indeed its creator. Nobody was disputing that.

Even if he was unsuccesful but tried long enough, that would still make him experienced.

I don't see how a detailed comparing of language successfullness would bring anything valuable to the point being made about the author being experienced. That seemed just a noise.

To me, this whole comment just screams inability to steelman.

Sure... and, to prove your point, Go has a package manager too (although it's a relatively new addition). But Go still follows a "batteries included" approach, where "standard" stuff (yes, even database handling) is handled by the standard library. Which still leaves lots of other things for which you need third party packages, but those will be typically far fewer than in other languages.

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

Reply on news.ycombinator.com