3 ms·
> I want less code. I want to limit the amount of 3rd party code I pull in. This is mostly due to supply chain disasters over on NPM scaring me and the amount o
by drnick1 10mo ago
> I want less code. I want to limit the amount of 3rd party code I pull in. This is mostly due to supply chain disasters over on NPM scaring me and the amount of code dependencies bringing in see rust dependencies scare me.
And this is basically why I like the C/C++ model of not having a centralized repo better. If I need some external piece of software, I simply download the headers and/or sources directly and place them in my project and never touch these dependencies again. Unless somehow these are compromised at the time of download, I will never have to worry about them again. Also these days I am increasingly relying on LLMs to simply generate what I need from scratch and rely less and less on external code.
- dkdcio 10mo agoyou could just do that with Rust, right? you’re just saying cargo makes it too easy not to I’m very tempted to go this direction myself with Rust, vendoring in and “maintaining” (using Claude Code to maintain) dependencies. or writing subsets of the crates I need myself and using those. the sprawl with Rust dependencies is concerning
- drnick1 10mo agoYes of course you could do this in Rust. It's just that every resource out there promotes the usage of Cargo, and sells this as an "improvement" over the old school way of managing dependencies manually.
- FridgeSeal 10mo agoCargo will let you vendor code into your repo easily. I think you’re conflating the tool, with how people manage deps. https://doc.rust-lang.org/cargo/commands/cargo-vendor.html https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
- rcxdude 10mo agoit's mainly an improvement because the rust ecosystem has a standardized way to build and distribute packages, so you can reliably add a dependency without build system pain. If you don't think having a reference to a central repo is a good way to go, you can vendor or even just pin your dependencies.
- umvi 10mo agoExternal C++ code never has CVEs? Or I guess since you are manually managing it, you are just ignorant of any CVEs?
- drnick1 10mo agoI suppose this largely depends on the kind of software that you write. Ideally, you also extract only the part of the external code that you need, audit it, and integrate it into your own code. This way you minimize the attack surface. I don't work on software that is exposed to the Internet however, so admittedly the importance of security vulnerabilities is low.
- Meneth 10mo agoI like using shared libraries from my Linux distro. Then I can rely on their automatic security updates to deal with any third-party vulnerabilities.
- vsgherzi 10mo agoI’d rather have cargo than not. Dependencies are opt in you don’t have to use them, which is what I’m trying to demonstrate here. The chrome team only uses what they need. Now the culture as a whole in rust in always that way but I believe that to mostly be due to the newness of the lang and the quality of libraries
- andrepd 10mo ago> Unless somehow these are compromised at the time of download, I will never have to worry about them again. But this is exactly what rust does x) `cargo add some_crate` adds a line `crate_name = "1.2.3"` to your project config, downloading and pinning the dependency to that exact version. It will not change unless you specifically change it.
- rcxdude 10mo agowell, not quite. It'll go into the lockfile and you won't get a new version if you just build again, but if you add or remove a dependency that version may shift around a bit as a part of dependency resolution.
- andrepd 10mo agoOnly if that different version is a dependency of a dependency. Your own will never change.
- brabel 10mo agoThat does not make the problem go away: now you'll have both versions in your dependency graph - hence you may be vulnerable to both version's CVEs.
- andrepd 10mo agoAny time you pull any code, be it `cargo add` or `apt install` or copy-pasting it in your own code, you become vulnerable to any issues present in that code. I'm unsure what your point is. The claim is just that `cargo add crate` is functionally identical to downloading a C++ header and keeping it in the same version, since in both cases the dependency will be pinned to that fixed version.
- nateb2022 10mo ago> but if you add or remove a dependency that version may shift around a bit as a part of dependency resolution cargo add crate@version is completely deterministic
- tempest_ 10mo agoThe C/C++ model should go back to 80s where it belongs. You can vendor deps with cargo if you want but fighting cmake/make/autoconf/configure/automake build spaghetti is not my idea of a good time.
- duped 10mo agoThis is called "vendoring" and any package manager that doesn't totally suck supports it, including cargo.