amos“every rust project has a billion dependencies”
oh no they made code composable oh nooooooo should we call someone??
Pixel Purrito@fasterthanlime the issue, more than having a number of dependencies, is: why these two programs use the same package as a dependency but won't reuse the same built artifacts, or better the same shared library? Why do I have to rebuild the same thing 386638957 times when I could do it just once when there is a security fix with the rest of the ecosystem picking the updated component without needing to rebuild the world and waste precious energy and time doing it?
@fasterthanlime don't take me wrong, I like Rust (the language itself), but I understand where the complaint comes from. The usual wording is... Not great.
Justin Ossevoort@aperezdc @fasterthanlime But would having fewer dependencies really solve that? And I really would like smarter sharing of build artifacts, but between feature flags and Rust coping with the “diamond dependency” problem you probably aren’t really compiling the same thing dozens of times, just a thing with the same name. Though it should still be possible to improve even that scenario.
@internetionals @fasterthanlime having less dependencies makes the issue somewhat less acute; and yes I am aware that it's not always exactly the same thing being rebuilt... but also I cannot help having the feeling that needing to have parts of crates built or not depending on a flag is something done to avoid bloating binaries *precisely* because there is no shared libraries. If shared libraries were possible, it wouldn't really matter that crate X always built feature Y even if many programs don't need feature Y: the code on disk would there be once, and also it wouldn't be taxing memory due to page sharing.
RAOF@aperezdc @internetionals @fasterthanlime Shared libraries are fundamentally in conflict with monomorphisation, which is somewhat of a problem for C++ (which is where header-only libraries come from) but is much more of an issue for Rust, where the idiomatic polymorphism is more tilted towards monomorphised generics.
(C++, true to form, changes this from a monomorphism problem into a basically-any-change-breaks-your-dependents problem)
@RAOF @internetionals @fasterthanlime while it's true that monomorphization makes things gnarlier, there are options, see https://faultlore.com/blah/swift-abi/
@RAOF @internetionals @fasterthanlime I particularly agree with the last note in that article: “but I think the key difference was ultimately just that Apple had a more significant motivation than Mozilla to pursue dynamic linking and way more resources to throw at this very hard problem.”
Amir Livne Bar-on@aperezdc @fasterthanlime
There's also probably some amount of administrative overhead. It's difficult to guarantee good quality & no malicious actors on a few large packages. But even more difficult on hundreds of small packages, especially once they've been almost-complete for a few years.
There's also probably some amount of administrative overhead. It's difficult to guarantee good quality & no malicious actors on a few large packages. But even more difficult on hundreds of small packages, especially once they've been almost-complete for a few years.
@Pashhur @fasterthanlime True that! QA is always a complicated topic, and having a myriad of dependencies doesn't help either. The stronger safety guarantees that Rust makes compared to other languages do help offset the issue a bit, though!