5 ms·
Regardless of language, really? I highly doubt that, you don't generally see such problems with C or even C++ because dependencies are more cumbersome to add, e
by harha_ 1y ago
Regardless of language, really? I highly doubt that, you don't generally see such problems with C or even C++ because dependencies are more cumbersome to add, especially in a way that's cross-platform.
- zaptheimpaler 1y agoBecause most dependencies are either manually installed by the user, or are dynamic libraries that are provided and audited by the distro maintainers. The dependencies are there, they're just harder to see - https://wiki.alopex.li/LetsBeRealAboutDependencies https://wiki.alopex.li/LetsBeRealAboutDependencies
- harha_ 1y agoSure, there are various dependencies, but it's nothing like "cargo install crate-name". Cargo makes it so effortless to joink the dumbest dependency for the simplest thing.
- zaptheimpaler 1y agoSure, I think software that's easy to use is a good thing and Rust dependency management is 100x nicer to work with than C++.
- tonyhart7 1y agoso what's the option??? I don't think this is only cargo-rust problem since you can do it too in another language
- crote 1y agoOn the other hand, C/C++ makes it attractive to reinvent the wheel, or vendor the dependency instead. Rather than a single well-tested implementation in the ecosystem for something like sha256, you end up with every application having its own slightly-different, mostly untested, and essentially unmaintained version. Applications still need the functionality. The need doesn't magically disappear when installing dependencies is a pain. If a crate has a bug, the entire ecosystem can trivially get the fixed version. If the Stackoverflow snippet a C app is vendoring has a bug, that fix is never getting in the app.
- uecker 1y agoThat does not help you if the bug is one of many unmaintained crates and never noticed. Linux distributions aim to make sure that C application dynamically link to the right libraries instead of vendoring the code. Then the library can be updated once. IMHO this is the only reasonable approach.
- kibwen 1y ago> Sure, there are various dependencies, but it's nothing like "cargo install crate-name". You don't install a Rust crate to use it. We have enough people in this thread trying to authoritatively talk about Rust without having any experience with it, please don't bother leaving a comment if you're just going to argue from ignorance.
- pjmlp 1y agoKind of true, when not using vcpkg/conan.
- hedora 1y agoDon’t forget cmake. (It makes adding dependencies easy, and everything else basically impossible)
- pjmlp 1y agoSure, despite all the hate it gets, except for IDE project files, it is the best experience in C and C++ build tools since forever, including IDE integration just like those project files. I thought the whole UNIX mentality was worse is better. No build tool is without issues, my pain points with cargo, are always compiling from source, build caching requires additional work to setup, as soon as it is more than pure Rust, we get a build.rs file that can get quite creative.
- Ygg2 1y agoAnd from Internals discussion (https://internals.rust-lang.org/t/add-some-form-of-precompiled-artifact-support-to-cargo/22871/7 https://internals.rust-lang.org/t/add-some-form-of-precompil...) it seems this causes more problems than it solves. It requires huge storage, for each combination of targets, and even if it is was solved some members of Rust community would see it as a step back. Me included. They are hard to audit and are step back to OSS nature of Rust.
- tialaramex 1y agoWith C++ it's hilarious because the C++ community is so allergic to proper dependency management and also so desperate for stuff from third party libraries that the committee spends large amounts of its time basically doing dependency management for the community by baking in large features you'd ordinarily take as a dependency into the mandatory standard library. I'm sure I'll miss some, but IIRC C++ 26 is getting the entire BLAS, two distinct delayed reclamation systems and all of the accompanying infrastructure, new container types, and a very complicated universal system of units. All of these things are cool, but it's doubtful whether any of them could make sense in a standard library, however for C++ programers that's the easiest way to use them... It's bedlam in there and of course the same C++ programmers who claim to be "worried" that maybe somebody hid something awful in Rust's crates.io are magically unconcerned that copy-pasting tens of millions of lines of untested code from a third party into absolutely every C++ program to be written in the future could be a bad idea.
- zahlman 1y ago> copy-pasting tens of millions of lines of untested code from a third party into absolutely every C++ program to be written in the future could be a bad idea. Is it really that bad? (By my count, as a point of reference, the Python 3.13 standard library is just under 900k lines for the .py files.)
- blub 1y agoIf something is in the standard library, then it’s written and vetted by the standard library provider, not by a random third party like you make it sound. With Rust, it’s literally a random third party.
- simonask 1y agoMaintainers of all open source standard libraries are effectively "random third parties". With heavily used ecosystem dependencies (such as Tokio, but also swaths of small libraries, such as `futures` or `regex`), the number of people who have looked at the code and battle-tested it is also huge. On crates.io, a good heuristic is to look at two numbers: the number of dependents and the number of downloads. If both are high, it's _probably_ fine. Otherwise, I'll manually audit the code. That's not a complete solution, especially not if you're worried about this from a security perspective, but it's a good approximation if you're worried about the general quality of your dependencies.