I'm not too familiar with Rust, but took a look at the Cargo.lock file of this project.
It depends on half the universe for some reason, sometimes multiple versions of the same library. And that doesn't even include the main dependency which is libclang.
There are a couple of aspects that can make lockfiles deceptive to look at
- Lockfiles include dependencies for all platforms, not just the ones you build with, including wasm and Hermit kernel
- Due to some quirks, lockfiles include more dependencies than will ever be used (related to a feature called "weak dependency features").
For a more accurate picture, look at `cargo tree` and `cargo tree --target=all`.
In this case, a lot of it is that the GitQL SDK depends on gix (gitoxide), a Rust re-implementation of git / libgit, which is made up of a lot of crates and depends on a lot of crates. This dependency should likely not be there and should be fixed. Even with `default-features = false`, gix pulls in a lot. Gix should not be relevant to a more generic SDK.
The other thing that stood out to me as unnecessary is that comfy-tables pulls in cross-term which has way too large of a dependency for what it is doing.
I am surprised at how much `chrono` pulls in but almost all of that is for specific platforms and `chrono` shrinks dramatically when looking only at the native platform.
I do see some stray dependencies that have built-in equivalents (lazy_static -> OnceCell, atty -> IsTerminal). Some of that is due to compatibility with old Rust versions. There were only a couple of these.
Dependency hell is a consequence of the developer's choices, not the ecosystem. The most foundational packages in any ecosystem for any language almost always have a trivial number of dependencies, and not because those packages have no needs.
Not quite to the extent of the js ecosystem, but yes. Especially for a purported systems language there's a lefpad-esque problem of people making tiny and somewhat useless libraries to learn or pad their resume which then get depended on by the world.
If foo needs bar at ^1 and baz needs bar at ^2 and you need foo and baz then your compile would fail if multiple versions weren't allowed. In other words, this is a feature not a bug.
> Is the Rust ecosystem just dependency hell?
No because "dependency hell" is where you can't resolve dependencies because of simple issues like above in ecosystems that can't handle it.
Also, currently the compilation unit in Rust is a single crate. If you had a lock file that contained all the .o files generated by all your dependencies in C it would be massive too!
Dependency hell means having many dependencies that are related to each other in non-trivial ways, making it difficult to ensure a compatible set of versions is maintained.
I think it's an inevitable outcome of a build system that makes it so easy to pull in packages - and so easy to create and publish them.
This is why C++'s weakness - difficulty of consuming third party libraries - is actually a strength. If you have to work hard to get third party code in there, you tend to make much better choices and keep your dependencies to a minimum.
In Rust, like JS and to a lesser extent Python also, there is no pressure to reduce dependencies. So you end up with this kind of a problem. Good luck upgrading one of those packages when its found to contain a bug.
It's not difficult to consume third party C++ libraries -- what's difficult is to ensure third party code is maintained up to your standards and compatible with all the other choices you've made about your environment.
It depends on half the universe for some reason, sometimes multiple versions of the same library. And that doesn't even include the main dependency which is libclang.
Is the Rust ecosystem just dependency hell?