Comment by smw
3 months ago
"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.
> 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.
2 replies →
"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.
1 reply →
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.
4 replies →
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.
15 replies →
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.
12 replies →
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.
2 replies →
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.
2 replies →
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).