alt Hacker News> 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.
Replies
I’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
I like using shared libraries from my Linux distro. Then I can rely on their automatic security updates to deal with any third-party vulnerabilities.
> 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.
External C++ code never has CVEs? Or I guess since you are manually managing it, you are just ignorant of any CVEs?
you 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
The 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.