3 ms·

Also unbelieveably, Rust has failed to address package balkanization which I would say has ruined the Node community. I'd say that this is more of a culture th

by Qasaur 7y ago

Also unbelieveably, Rust has failed to address package balkanization which I would say has ruined the Node community. I'd say that this is more of a culture thing rather than a language thing.

thesuperbigfrog 7y ago
Whether culture or language, if it is not addressed then expect similar results :(
- dom96 7y ago
  The primary way I can see to address this is to make packaging more difficult. Are there other steps that a language can take to avoid this problem?
  - thesuperbigfrog 7y ago
    A few ideas: 1) Remove the ability to unpublish / yank crates. A published crate should be immutable, but the crate's metadata should always be updateable by the maintainer. 2) Improve the metadata that describes a crate so that it is easy to tell if a crate should be used. For example, is the crate beta quality? Was a serious error found in the crate and it needs to be marked as "not safe"? Is it a Long-Term Support release? Etc. 3) As a culture, disallow trivial crates. No "is-odd" or similarly low effort crates. These just add bloat since the have so little functionality compared to their overhead. If your crate's toml is larger than the crate's code, you are doing it wrong.
    - chc 7y ago
      Ironically, "no trivial crates" is almost exactly the opposite of what the article seems to want, which is only small crates so you're not importing lots of needless bloat. It's hard to please everyone!
      - raphlinus 7y ago
        I talk about this a bit, I'm in favor of at least medium granularity crates, but if they break down into smaller features, where different use cases will meaningfully choose different sets of features, use feature gates. So, for example, you might have a "string formatting utilities" crate with a "left-pad" feature. (Note: this particular example is unlikely because the `format!` macro in the standard library can do it just fine)
  - JackC 7y ago
    AFAIK the real problem in node is not number of packages in itself, but number of independent trust relationships implied by transitive dependencies. Basically how many separate people's integrity and security practices are you counting on when you install your reqs? So a language could: - identify a blessed set of packages that don't imply separate trust relationships (a stdlib, or packages maintained or audited by the language team) - require strong security practices and/or trust metrics from package authors - clearly expose the full list of authors implicitly trusted by a requirements file - offer community auditing tools, such as reproducible builds if delivering compiled files, web of trust tools, or diff tools - run internal tests for suspicious packages (and don't talk about them) If you frame the problem differently the solutions might be different, but I suspect there would still be a bunch of options.
  - Myrmornis 7y ago
    You could require that packages pass community review before they're allowed to be published on (the main) registry. Emacs-lisp (Melpa) does this. Although it's a different thing, Homebrew does that also.

by Qasaur 7y ago

Also unbelieveably, Rust has failed to address package balkanization which I would say has ruined the Node community. I'd say that this is more of a culture thing rather than a language thing.

thesuperbigfrog 7y ago

Whether culture or language, if it is not addressed then expect similar results :(

dom96 7y ago
The primary way I can see to address this is to make packaging more difficult. Are there other steps that a language can take to avoid this problem?
- thesuperbigfrog 7y ago
  A few ideas: 1) Remove the ability to unpublish / yank crates. A published crate should be immutable, but the crate's metadata should always be updateable by the maintainer. 2) Improve the metadata that describes a crate so that it is easy to tell if a crate should be used. For example, is the crate beta quality? Was a serious error found in the crate and it needs to be marked as "not safe"? Is it a Long-Term Support release? Etc. 3) As a culture, disallow trivial crates. No "is-odd" or similarly low effort crates. These just add bloat since the have so little functionality compared to their overhead. If your crate's toml is larger than the crate's code, you are doing it wrong.
  - chc 7y ago
    Ironically, "no trivial crates" is almost exactly the opposite of what the article seems to want, which is only small crates so you're not importing lots of needless bloat. It's hard to please everyone!
    - raphlinus 7y ago
      I talk about this a bit, I'm in favor of at least medium granularity crates, but if they break down into smaller features, where different use cases will meaningfully choose different sets of features, use feature gates. So, for example, you might have a "string formatting utilities" crate with a "left-pad" feature. (Note: this particular example is unlikely because the `format!` macro in the standard library can do it just fine)
- JackC 7y ago
  AFAIK the real problem in node is not number of packages in itself, but number of independent trust relationships implied by transitive dependencies. Basically how many separate people's integrity and security practices are you counting on when you install your reqs? So a language could: - identify a blessed set of packages that don't imply separate trust relationships (a stdlib, or packages maintained or audited by the language team) - require strong security practices and/or trust metrics from package authors - clearly expose the full list of authors implicitly trusted by a requirements file - offer community auditing tools, such as reproducible builds if delivering compiled files, web of trust tools, or diff tools - run internal tests for suspicious packages (and don't talk about them) If you frame the problem differently the solutions might be different, but I suspect there would still be a bunch of options.
- Myrmornis 7y ago
  You could require that packages pass community review before they're allowed to be published on (the main) registry. Emacs-lisp (Melpa) does this. Although it's a different thing, Homebrew does that also.