4 ms·

I'd guess the Node.js and npm got composability w/ approachability formula the most correct. Rust comes close but using rust libraries is where approachability

I'd guess the Node.js and npm got composability w/ approachability formula the most correct. Rust comes close but using rust libraries is where approachability falls apart fast. As for editors. Right now vscode get that formula the most correct. As for Unix what do we have to compare it too? Everything more or less is a Unix these days. So it couldn't have got approachability that wrong.

SQueeeeeL 4y ago
I think the issue with npm is that it makes what should be a relatively important task (adding huge swathes of mostly unknown code) trivial to do, leading to all the bloat and abuse that ecosystem has seen. Sometimes a bit of friction that forces the user to slow down and truly understand what they're doing is a good thing...
- shadowgovt 4y ago
  The vulnerable part of the npm ecosystem is trust and end-user high-granularity control of trust. If that problem can be solved, there's nothing inherently problematic with just using large swathes of mostly unknown code. Almost no Debian user knows the innards of every package they've installed, even the dev libraries they're building new applications on top of (to say nothing of every Ubuntu user). (TBF to the ecosystem, there actually is a mechanism for flagging security issues in old library versions and surfacing those to a package builder. But it is up to the package builder to account for them by changing their dependencies).
  - __MatrixMan__ 4y ago
    I agree. To be more specific I think the problem with npm is that it explicitly trusts names and implicitly trusts their referents, which puts too heavy a burden on the name resolver. Contrast this with apt, which inspects package signatures and compares them to keys I've trusted. If a package shows up with the same name as before, but different bits, and it's signed by somebody new, I have a reason to scrutinize it more heavily.
shadowgovt 4y ago
Npm does one thing particularly clever that a lot of other library / dependency infrastructures fail at: it supports multiple versions of the same library living in the codebase. Because npm treats package dependencies recursively, a package depending on v1 of another package and a package depending on v2 of that package can actually live in the same codebase (with proper configuration; it comes as kind of a side-effect of transpilation and tree-shaking requiring the toolchain to rename symbols anyway, so the two different versions of the library just end up either properly hidden via module inclusion or in the same codebase but name-mangled to different things). This isn't foolproof (if one of those libraries leaks details of its dependency, and another piece of code tries to do `instanceof`, it's going to have a bad time), but it makes it easier to work with codebases one doesn't control.

SQueeeeeL 4y ago

I think the issue with npm is that it makes what should be a relatively important task (adding huge swathes of mostly unknown code) trivial to do, leading to all the bloat and abuse that ecosystem has seen. Sometimes a bit of friction that forces the user to slow down and truly understand what they're doing is a good thing...

shadowgovt 4y ago
The vulnerable part of the npm ecosystem is trust and end-user high-granularity control of trust. If that problem can be solved, there's nothing inherently problematic with just using large swathes of mostly unknown code. Almost no Debian user knows the innards of every package they've installed, even the dev libraries they're building new applications on top of (to say nothing of every Ubuntu user). (TBF to the ecosystem, there actually is a mechanism for flagging security issues in old library versions and surfacing those to a package builder. But it is up to the package builder to account for them by changing their dependencies).
- __MatrixMan__ 4y ago
  I agree. To be more specific I think the problem with npm is that it explicitly trusts names and implicitly trusts their referents, which puts too heavy a burden on the name resolver. Contrast this with apt, which inspects package signatures and compares them to keys I've trusted. If a package shows up with the same name as before, but different bits, and it's signed by somebody new, I have a reason to scrutinize it more heavily.

shadowgovt 4y ago

Npm does one thing particularly clever that a lot of other library / dependency infrastructures fail at: it supports multiple versions of the same library living in the codebase. Because npm treats package dependencies recursively, a package depending on v1 of another package and a package depending on v2 of that package can actually live in the same codebase (with proper configuration; it comes as kind of a side-effect of transpilation and tree-shaking requiring the toolchain to rename symbols anyway, so the two different versions of the library just end up either properly hidden via module inclusion or in the same codebase but name-mangled to different things). This isn't foolproof (if one of those libraries leaks details of its dependency, and another piece of code tries to do `instanceof`, it's going to have a bad time), but it makes it easier to work with codebases one doesn't control.