4 ms·

I personally suspect it's an effect of the over reliance of the package manager approach to software development that rust and a few other languages use, which

I personally suspect it's an effect of the over reliance of the package manager approach to software development that rust and a few other languages use, which itself is an unintended to consequence of a well designed library import system. Languages where importing a library is hard, libraries tend to grow quite large. Large libraries have larger backing, more established development and security protocols. When OpenCV, TinyUSB, Numpy, nimBLE start to struggle, it's easier to notice and companies relying on them may step up to fork, maintain of fund its continued use. Languages where importing and creating a library is easy, we see small atomic packages for small utility programs, over large libraries. This spreads the software supply-chain wider, into smaller teams of maintainers. If the same amount of code is fractured over 50 small libraries maintained by 1-3 people each, the likelihood of one or two becoming abandoned grows. I've been a bit weary about the dependency and package manager approach more modern languages use. It trades convenience for some pretty scary supply-chain attacks.

normie3000 1y ago
I haven't seen this perspective before but it's a very elegant explanation for why e.g. npm is so much scarier than maven. I wonder if safety could be improved a little if private package management was easier than throwing things out in public.
- Veserv 1y ago
  Newer languages have made packaging and importing dependencys significantly easier, but have done this while increasing coupling and making switching dependencys harder. This results in brittle dependency trees. Using a private package manager, intermixing private and public, and substituting arbitrary dependencys with compatible alternatives, i.e. modularity, should be easy. Only then does solving the problem become easy. What we used to have is a big ball of mud. Modern languages made it easier to decompose a system into components. But what we really want is easily decomposing a system into modular components which is yet unsolved.
  - int_19h 1y ago
    > What we used to have is a big ball of mud. Modern languages made it easier to decompose a system into components. But what we really want is easily decomposing a system into modular components which is yet unsolved. We need to take modularity a lot more seriously, and by this I don't mean just making things more pluggable, but also well-defined component boundaries and contracts on them. Sadly a lot of this stuff is moving at a glacial pace, and little of it is mainstream. Design-by-contract was introduced 40 years ago, and yet no mainstream PL in use offers anything past the bare minimum (asserts). Niche tech like Ada SPARK is picking it up, but even there it took decades. And now we throw AI into the mix and expect things to work. Madness.
kibwen 1y ago
But Rust doesn't have an abundance of small/atomic libraries. This is describing NPM, not crates.io. Rust doesn't have the same culture as Node.
- eqvinox 1y ago
  There might be fewer small crates, but I've still seen massive dependency lists. Case in point: tokio. How many "related" crates do you deal with for various features? 5? 50? It's not great.
- pjmlp 1y ago
  Say what? Any Rust project has endless crates scrolling up the screen. It has exactly the same culture as npm, which is no wonder, because many folks adopting Rust come from Web background, not C and C++.
  - kibwen 1y ago
    No, this is mistaken. A crate is both rustc's unit of compilation and Cargo's unit of dependency. Feel free to lament this conflation all you like, but what it means is that the common pattern is for library authors to publish large crates that are internally split into smaller crates for better compilation parallelism. This just isn't a problem by any metric; it doesn't increase your trusted computing base. That's not at all the same problem as NPM has with its web of frivolous micro-dependencies.
    - pjmlp 1y ago
      It is surely a problem given the cumulative time everyone waits compiling them distributed across Rust users. Also if it wasn't a problem, articles like this wouldn't exist, https://tweedegolf.nl/en/blog/104/dealing-with-dependencies-in-rust https://tweedegolf.nl/en/blog/104/dealing-with-dependencies-...
      - woodruffw 1y ago
        This is backwards: per GP, the cumulative time would be greater if there were fewer crates, because of how incremental and parallel compilation work in Rust. (This doesn’t mean Rust doesn’t have a dependency proliferation issue, only that the way you’re substantiating it is misleading: it’s like saying that C has a dependency proliferation issue because libfoo goes from having 3 source files to 5 source files between releases.)

normie3000 1y ago

I haven't seen this perspective before but it's a very elegant explanation for why e.g. npm is so much scarier than maven. I wonder if safety could be improved a little if private package management was easier than throwing things out in public.

Veserv 1y ago
Newer languages have made packaging and importing dependencys significantly easier, but have done this while increasing coupling and making switching dependencys harder. This results in brittle dependency trees. Using a private package manager, intermixing private and public, and substituting arbitrary dependencys with compatible alternatives, i.e. modularity, should be easy. Only then does solving the problem become easy. What we used to have is a big ball of mud. Modern languages made it easier to decompose a system into components. But what we really want is easily decomposing a system into modular components which is yet unsolved.
- int_19h 1y ago
  > What we used to have is a big ball of mud. Modern languages made it easier to decompose a system into components. But what we really want is easily decomposing a system into modular components which is yet unsolved. We need to take modularity a lot more seriously, and by this I don't mean just making things more pluggable, but also well-defined component boundaries and contracts on them. Sadly a lot of this stuff is moving at a glacial pace, and little of it is mainstream. Design-by-contract was introduced 40 years ago, and yet no mainstream PL in use offers anything past the bare minimum (asserts). Niche tech like Ada SPARK is picking it up, but even there it took decades. And now we throw AI into the mix and expect things to work. Madness.

kibwen 1y ago

But Rust doesn't have an abundance of small/atomic libraries. This is describing NPM, not crates.io. Rust doesn't have the same culture as Node.

eqvinox 1y ago
There might be fewer small crates, but I've still seen massive dependency lists. Case in point: tokio. How many "related" crates do you deal with for various features? 5? 50? It's not great.
pjmlp 1y ago
Say what? Any Rust project has endless crates scrolling up the screen. It has exactly the same culture as npm, which is no wonder, because many folks adopting Rust come from Web background, not C and C++.
- kibwen 1y ago
  No, this is mistaken. A crate is both rustc's unit of compilation and Cargo's unit of dependency. Feel free to lament this conflation all you like, but what it means is that the common pattern is for library authors to publish large crates that are internally split into smaller crates for better compilation parallelism. This just isn't a problem by any metric; it doesn't increase your trusted computing base. That's not at all the same problem as NPM has with its web of frivolous micro-dependencies.
  - pjmlp 1y ago
    It is surely a problem given the cumulative time everyone waits compiling them distributed across Rust users. Also if it wasn't a problem, articles like this wouldn't exist, https://tweedegolf.nl/en/blog/104/dealing-with-dependencies-in-rust https://tweedegolf.nl/en/blog/104/dealing-with-dependencies-...
    - woodruffw 1y ago
      This is backwards: per GP, the cumulative time would be greater if there were fewer crates, because of how incremental and parallel compilation work in Rust. (This doesn’t mean Rust doesn’t have a dependency proliferation issue, only that the way you’re substantiating it is misleading: it’s like saying that C has a dependency proliferation issue because libfoo goes from having 3 source files to 5 source files between releases.)