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

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

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.

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.

I guess clickbait is evil

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

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.