Hacker News Reader

Comment by turminal | Hacker News Reader

This just saddens me deeply. Of all the ways this could have been done and all the package managers they could have used they picked npm.

I bet some day we'll have a Linux distro with npm as the system package manager here on HN.

View on HN

It saddens you that someone used a tool they already use instead of adding another thing to distribute a small binary?

I guess my comment appears rude, which wasn't intended, I just find npm a troublesome piece of software that is passable as a package manager for the javascript ecosystem, but not a tool one solves problems with if there are viable alternatives.

why is it trouble? why can't they improve it even if its trouble?

When you have one thing to nail and already own a hammer, why go and buy another one? Even if it's not a good one, it's gonna do the job, and be the least trouble.

The choice of package manage is much stickier than the choice of hammer. I can trivially change hammers between projects or even between nails. Changing package managers is a lot more involved, and gets more involved as it's used more---and they've just established a precedent for using npm to package go binaries.

They established the choice of npm when they choose to be a JS shop, that's exactly their argument.

Sorry I wasn't clear, I'm not making an argument for or against npm, only responding to the analogy.

But I wouldn't consider "we're already using X" to be sufficient reason to use X for something it wasn't designed around. Again, these choices are sticky and tend to be vulnerable to scope creep. I'd call it a textbook case of technical debt, and it's ok to point that out. They might have forestalled the criticism by acknowledging that, but they didn't.

Meh, depends. For their case, for an internal CLI tool that will get used interactively on development environments, it's fine, the cost of switching is not very heavy. At worst they're postponing the work of deploying on other package managers, and devs will have to run 2-3 commands to remove the npm package, configure whatever next place it gets deployed to and install the new executable.

Not a big deal at all.

Sure, should have s/much stickier/sticker/. I'm not going to comment on whether the tradeoffs are worth it, I just thought the hammer analogy doesn't work due to material differences in how you switch between hammers vs package managers.

I don't know why but I never encountered issues using npm.

I've had far more problems with yarn, which sometimes decides it and it alone not longer has internet access and none of the "fixes" published over the years have worked. Instead, you have to just set your timeout really, really high. That's been the only fix for a good while, and it frequently does not work.

Older NPM could be a pain but modern NPM is pretty smooth and works just fine.

deeply

I thought the same thing (Go binaries are so easy to distribute), but they do explain that their devs already have credentials for an internal NPM server, and they wanted to do this "without the need of distributing a new set of tokens or making the binary public". I don't think the trade-off is worth it, but at least it explains their motivation.

In their particular case, what's the trade-off that's so terrible though? They already all have npm, they had a binary to distribute, and they distributed it.

https://node-os.com/

Dang, I wish I could say I'm surprised, but I guess it was to be expected.

Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.

Reply on news.ycombinator.com