Nah. The Rust compiler's warnings are wonderful, as ever: https://github.com/rust-lang/rust/blob/master/src/librustc/i...
That is actually a fairly recent addition. I wasted like 2 days of my time trying to find the bug until someone pointed out it could be differing versions of the crate.
Re:Rust Solved Dependency Hell
by babyloneleven on Thursday July 18, 2019 @07:07AM
(#20468561)
The rayon crate has a global state: the entire program must use the same thread pool, even if different crates depend on different rayon versions.
It uses a Cargo feature meant to be used by native libraries: you typically can link them only once (or else the build will fail when it finds repeated symbols), so Cargo must ensure only one is present on the entire dependency graph. And IIRC Rayon depends on an auxiliary crate that fakes a native lib and provides the thread pool.
If this seems very hacky and convoluted, it's because it is.
If you rely on global state, this global state is also mangled to a different symbol, this might be undesirable.
For example, if you use a logger which relies on a extern defined variable. Your singleton is duplicated.
Also all your code is duplicated.
I agree that how rust does it is a very nice solution.
Are there any circumstances in which this approach can have undesirable behavior, for example if the dependency has to deal with some global state?
This seems like the kind of thing that could create difficult-to-understand problems if Cargo gives you two copies of a dependency only under specific and rare circumstances. (But I'm happy to be proven wrong, and I'm sure the Rust folks have thought this through more carefully than I have.)