Hacker News Reader

Comment by drnick1 | Hacker News Reader

> 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.

View on HN

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.

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.

This is called "vendoring" and any package manager that doesn't totally suck supports it, including cargo.

> 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.

well, 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.

Only if that different version is a dependency of a dependency. Your own will never change.

That 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.

Any 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.

> 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

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

Yes 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.

Cargo 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

it'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.

External C++ code never has CVEs? Or I guess since you are manually managing it, you are just ignorant of any CVEs?

I 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.

Reply on news.ycombinator.com