You can't really count "dependencies" in the Rust ecosystem by counting the number of crates. Gix itself has 65 crates but if you depended on it that would only really be one dependency.
Your average Rust project will have more dependencies than your average C project, but it's not as dramatic as you might think.
Okay, but when I compile a Rust project and I see "0/2000" that gets pulled and built, I panic.
> You can't really count "dependencies" in the Rust ecosystem by counting the number of crates.
Can you elaborate as to why? I have much less packages (many of them are not even C libraries) installed by my operating system than what a typical Rust project pulls and builds.
Because Rust crates are the "compilation unit" as well as the "publishing unit". So if you are a largish library then you'll likely want to split your library across several crates (to enable things like parallelism in the build process). Then you'll end up with several crates from the same git repo, same developers, that will show up individually in the raw crate count.
It's not a perfect analogy (because crates are generally multiple files), but imagine if in a C project you counted each header file as a separate dependency, it's kinda like that.
---
There is a culture in the Rust ecosystem of preferring shared crates for functionality rather than writing custom versions of data structures or putting too much in the standard library (although it's not nearly so extreme as in the JavaScript ecosystem). And I do think the concern around supply-chain attacks is not entirely unwarranted. But at the same time, the quality standards for these crates are excellent, and in practice many of them are maintained by a relatively small group of people that as a Rust developer I know and trust.
And are these dependencies that get pulled and built general-purpose? I presume it is since it is published, but I have no idea if it is indeed general-purpose, or something like "internal/*/*" in Go where the code is not supposed to be used by any other codebase.
This is four crates, so it shows up as 4/2000. But last week, it would have been 3/2000, because serde_core was extracted very recently: https://github.com/serde-rs/serde/pull/2608
As a serde user, this reorganization doesn’t change the amount of code you’ve been depending on, or who authors that code, but it did add one more crate. But not more actual dependency.
So, I have been complaining about how Rust projects have over hundreds and often thousands of dependencies. I gave this random Rust project a try.
The results:
No thank you.Can you Rust people stop doing this? Hundreds of dependencies is the norm in Rust culture. I swear humans will never learn.
You can't really count "dependencies" in the Rust ecosystem by counting the number of crates. Gix itself has 65 crates but if you depended on it that would only really be one dependency.
Your average Rust project will have more dependencies than your average C project, but it's not as dramatic as you might think.
Okay, but when I compile a Rust project and I see "0/2000" that gets pulled and built, I panic.
> You can't really count "dependencies" in the Rust ecosystem by counting the number of crates.
Can you elaborate as to why? I have much less packages (many of them are not even C libraries) installed by my operating system than what a typical Rust project pulls and builds.
> Can you elaborate as to why?
Because Rust crates are the "compilation unit" as well as the "publishing unit". So if you are a largish library then you'll likely want to split your library across several crates (to enable things like parallelism in the build process). Then you'll end up with several crates from the same git repo, same developers, that will show up individually in the raw crate count.
It's not a perfect analogy (because crates are generally multiple files), but imagine if in a C project you counted each header file as a separate dependency, it's kinda like that.
---
There is a culture in the Rust ecosystem of preferring shared crates for functionality rather than writing custom versions of data structures or putting too much in the standard library (although it's not nearly so extreme as in the JavaScript ecosystem). And I do think the concern around supply-chain attacks is not entirely unwarranted. But at the same time, the quality standards for these crates are excellent, and in practice many of them are maintained by a relatively small group of people that as a Rust developer I know and trust.
And are these dependencies that get pulled and built general-purpose? I presume it is since it is published, but I have no idea if it is indeed general-purpose, or something like "internal/*/*" in Go where the code is not supposed to be used by any other codebase.
Lots of projects break themselves up into multiple crates for various reasons, but they’re still maintained as a whole by the same people.
Take serde, for example: https://github.com/serde-rs/serde
This is four crates, so it shows up as 4/2000. But last week, it would have been 3/2000, because serde_core was extracted very recently: https://github.com/serde-rs/serde/pull/2608
As a serde user, this reorganization doesn’t change the amount of code you’ve been depending on, or who authors that code, but it did add one more crate. But not more actual dependency.