Comment by pjmlp
1 day ago
Also there is a certain npm feeling, every time I try out some trendy project, endless list of crates being compiled, even more interesting is seeing some being compiled multiple times.
1 day ago
Also there is a certain npm feeling, every time I try out some trendy project, endless list of crates being compiled, even more interesting is seeing some being compiled multiple times.
I agree it is a problem. Though in my experience it's still not as bad as NPM. I still know what most of the dependencies do, even when there are hundreds. And you usually get hundreds of dependencies only for things that simply do a lot. E.g. one of my projects has hundreds of dependencies but that's because it includes wasmtime, which feels fairly justified.
In NPM you often get thousands of dependencies for things that should be simple like Vue.
Another factor is that projects are often split into many crates for compile time & modularity reasons, e.g. Gix is dozens of crates.
The "two versions of a crate" is actually a great thing. In other ecosystems like Python you would be simply unable to build the project at all because you can only have one version of any dependency.
The one thing that I think is a big problem is where you have splits in the ecosystem, e.g. anyhow vs snafu, or Tokio Vs Smol. Once your project gets to a certain size you end up including every vaguely popular error handling crate. I think that's one of the big downsides of a small standard library which I haven't heard anyone mention.
I mention that problem all the time.
I rather have a wonky standard library that works everywhere the full implementation is available, than this jigsaw mess, that isn't guaranteed to work everywhere.
Is also why alongside rich standard libraries, I am also quite fond of frameworks and middleware over plain libraries.