4 ms·
Rust suffers from the same faults as the JS ecosystem. Any significant crate imports hundreds if not thousands of dependencies. The probability that one of the
by hbbio 28d ago
Rust suffers from the same faults as the JS ecosystem. Any significant crate imports hundreds if not thousands of dependencies. The probability that one of the authors gets targeted by AI-assisted attacks is just too high.
Also most of these dependencies provide a breadth of features that the end package does probably not need.
- dwroberts 28d agoMy experience has been that it has a major advantage, in that freeze + offline actually work properly. You can collect the dependencies you need once, put them in version control and never ever talk to remote registry again
- LtWorf 27d agoYou mean leave all CVEs open?
- dwroberts 27d agoI guess that’s more of a problem if you use all-encompassing frameworks, but normally the things I’m using are very small components where the CVEs either don’t exist or are inconsequential/unexploitable for the programs I’m building
- LtWorf 27d agoSo you don't track them, have no way of tracking them and just hope for the best. I hope no customer of yours asks for an SBOM :D
- dwroberts 27d agoUpdating every dependency for every kind of CVE is a brute force method for people and organisations that don’t understand the attack surface of the programs they’re producing
- LtWorf 27d agoAnd vendoring without having any idea of what is in there and doing no monitoring is peak engineering?
- dwroberts 27d agoWho is doing what you’re describing? The reason I can confidently freeze and offline stuff is because I’m not taking in whole frameworks, I’m selecting things carefully, and generally do end up reading at least most of the source And what ‘monitoring’ are you going to be doing besides things like CVEs?
- account42 28d agoYes, the lack of a language package manager for older programming languages is a feature.
- quikoa 28d agoA language without a large stdlib pushes this that functionality into (transitive) dependencies. I hope more language will adopt batteries included approach.
- thayne 28d agoNo stdlib will ever include all the "batteries" you need. And large stdlibs have their own set of problems, like stagnation, tying the library version to the language version, backwards compatibility garantees preventing evolution, and either needing a wide range of domain experts to maintain it, or having developers maintain components they don't have a deep understanding of. I think the sweet spot is having an ecosystem of "blessed" libraries that are reviewed for security and quality, but are versioned independently of the language, and maintained by subject matter experts.
- wmedrano 27d agoThis particular crate (arrayref) seems pretty niche, but also doable in std now. It lets you take a slice `&[T]` and return a slice with a known number of elements`&[T; N]`. tiny-skia was probably using this to get some SIMD optimizations. As of Jan 2026, this seems to be in the standard library under slice::as_array https://doc.rust-lang.org/std/primitive.slice.html#method.as_array https://doc.rust-lang.org/std/primitive.slice.html#method.as...
- rfgplk 27d agoYep. Sorry for the spam, but look at this, compiling "yazi" from source (ie a relatively simple TUI file manager) 676 dependencies: Downloaded by_address v1.2.1 Downloaded block-buffer v0.12.1 Downloaded block-padding v0.4.2 Downloaded adler2 v2.0.1 Downloaded color_quant v1.1.0 Downloaded blowfish v0.10.0 Downloaded byteorder v1.5.0 Downloaded bytemuck_derive v1.12.0 Downloaded futures-sink v0.3.34 Downloaded bs58 v0.5.1 Downloaded critical-section v1.2.0 Downloaded fnv v1.0.7 Downloaded bytemuck v1.25.2 Downloaded form_urlencoded v1.2.2 Downloaded futures-macro v0.3.34 Downloaded futures-io v0.3.34 Downloaded blake2 v0.11.0-rc.6 Downloaded find-msvc-tools v0.1.11 Downloaded funty v2.0.0 Downloaded fdlimit v0.3.0 Downloaded ff v0.14.0 Downloaded foldhash v0.2.0 Downloaded bon v3.9.3 Downloaded fdeflate v0.3.7 Downloaded darling_core v0.23.0 Downloaded bon-macros v3.9.3 .... Compiling clap v4.6.6 Compiling tokio-util v0.7.19 Building [===============> ] 451/676: ecdsa, exr, yazi-shared, regex-automata,
- jiggawatts 27d ago'bs58' jumped out at me as a random looking package name. It implements the base58 encoding, which is used primarily by... Bitcoin. I'd love to see the explanation of why "a TUI file manager" needs a crate closely associated with crypto coins and not much else. It is precisely this kind of thing that makes Rust a no-go for most enterprises. "I just want a CLI tool." "Congratulations, your servers are mining crypto!" PS: bs58 is maintained by one anonymous person and their package is used in just about every Rust crypto library and hence application. Compromise his account in the same manner as the 'xz tools' attack and you could still billions in crypto!
- robwayne 27d agoIt doesn't actually use it, this is just referencing it in the dependency graph (Cargo.lock). bs58 is an optional (feature-gated) transitive dependency of another crate, which is never referenced at all in the top-level crate. The build.rs doesn't run or anything. I believe there's (several) open issues about changing this behavior of the lock file, but I have moved on from Rust so don't know the status of things. That said, this is confusing behavior. I remember I first noticed it when a bunch of crates were showing up in my lock file for every OS under the sun, even though I was specifically using a "wayland" (linux-only) feature. Not to defend Rust's crazy culture of dependencies, mind you.