6 ms·

Rust bloat is a serious issue that is not being taken seriously I think. I raised the issue about platform size in June: https://github.com/rust-lang/rust/issu

• 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.
• ChrisSD 7y ago
  Unless I've misunderstood you, that would appear to be a different issue. The size of Rust platform tools doesn't necessarily lead to longer build times or bloat for applications built with Rust. And IMHO your issue does appear to be being taken seriously, at least judging from the link provided.
• sergiotapia 7y ago
  Please no, is Rust following the node path of tumors that is the npm
• robocat 7y ago
  > package balkanization Balkanize definition: to break up (a region, a group, etc.) into smaller and often hostile or uncooperative units. Are you implying there are competing crates with belligerent attitudes to each other? > which I would say has ruined the Node community I thought it was the basis and strength of node... (However I am too scared to use node or node toolchains: I fear trojans since I don't trust all dependencies).
  • jacobolus 7y ago
    One sovereign political unit (the Ottoman Empire) was weakened by ethnic nationalism (alongside political decay, external pressure, etc.); ended up in war; and the Balkan region was broken into several small states. Instead of being able to make regional policy, amortize common costs, suppress local divisions under a common rule, communally defend against outside pressure/threats, etc., these new states were weak and unstable. Ultimately their conflict drew in outside powers and led to the first world war. The suggestion in this context is that if a library is replaced by several pieces, they will adopt different conventions, duplicate effort, not interoperate as freely, etc., instead of benefiting from a unified vision and design.
• Scuds 7y ago
  Great job commenting on a four year old thread on the package manager instead of going to the package maintainers themselves.