Rust Dependency Issues

Fundamentally there is no difference. In practice Rust makes things a lot worse. It encourages the use of dependencies from random (i.e. published with cargo) sources without much quality control. It is really a supply chain disaster to happen. A problem like this would propagate much faster. Here the threat actor had to work hard to get his library updated in distributions and at each step there was a chance that this is detected. Now think about a Rust package automatically pulling in transit

It's surprising to me that this was downvoted. Many a Rust project pulls several hundred Cargo dependencies that the developer probably hasn't even checked against basic things like outstanding bugs. The lack of standard package management in C++ sometimes is for the best.

I love Rust, but as a daily C++ user (embedded microcontrollers, not supported by Rust yet, and then native Linux tooling to interface with them) what I find most frustrating about Rust is the number of crates that need to be knit together to make working software. Often these crates are from a single dev who last committed in 2020 or something. I really wish there was something like go’s standard library in Rust. That has been my barrier to adoption, and believe me I WANT to use it at work and

I think several of the responses to your comment are misguided. If you believe them you'd think that the reason this is to be expected for Rust (and even normal! good!) is that (a) Rust is a systems language, (b) Rust deliberately has a small standard library, and (c) it doesn't matter anyway because compiles are cached.I'd say, first of all, that it does matter, because very few projects with hundreds of (transitive) dependencies are going to be able to take security su

This is a natural and not really scary thing.All code is built on mountains of dependencies that by their nature will do more than what you are using them for. For example, part of cargo watch is to bring in a win32 API wrapper library (which is just autogenerated bindings for win32 calls). Of course that thing is going to be massive while watch is using only a sliver of it in the case it's built for windows.The standard library for pretty much any language will have millions of lin

I am very concerned about Rust.Rust’s “decision” to have a very slim standard library has advantages, but it severely amplifies some other issues. In Go, I have to pull in zero dependencies to make an HTTP request. In Rust, pulling reqwest pulls in at least 30 distinct packages (https://lib.rs/crates/reqwest). Date/time, “basic” base64, common hashing or checksums, etc, they all become supp

Rust is an interesting case to me.There are certainly a lot of libraries on crates.io, but I’ve noticed more projects in that ecosystem are willing to push back and resist importing unproven crates for smaller tasks. Most imported crates seem to me to be for bigger functionality that would be otherwise tedious to maintain, not something like “is this variable an array”.(Note that I’m not saying Rust and Cargo are completely immune to the issue here)

In the context of Rust it is not about "bloat" indeed. The compiler includes only used bits and nothing more. However, there are other problems, like the software supply chain security. More dependencies you have, more projects you have to track. Was there a vulnerability that affects me? Is project unmaintained and some ill factor took it over?In C this was actually a less problem since you had to copy-paste the shared code into your program and at some level you were manually revi

Rust has dependency hell and supply chain attacks like with npm.

On the other hand, rust has no standard library ("batteries") by explicit choice, so once the ecosystem will evolve, there would likely be multiple json or http libraries (just to name "low-level" libraries with widespread usage), and you might end up linking a few of them in a binary as indirect dependency.