3 ms·

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 troub

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.

andreareina 6y ago
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.
- detaro 6y ago
  They established the choice of npm when they choose to be a JS shop, that's exactly their argument.
  - andreareina 6y ago
    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.
- folkrav 6y ago
  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.
  - andreareina 6y ago
    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.

3 ms·

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 troub

by folkrav 6y ago

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.

andreareina 6y ago
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.
- detaro 6y ago
  They established the choice of npm when they choose to be a JS shop, that's exactly their argument.
  - andreareina 6y ago
    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.
- folkrav 6y ago
  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.
  - andreareina 6y ago
    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.