Hacker News Reader

Comment by joshheitzman | Hacker News Reader

Because the memory safety Rust offers isn't worth the supply chain risks: https://safeguard.sh/resources/blog/rust-supply-chain-securi...

View on HN

A problem that C solves by simply not having a supply chain! You can vendor dependencies in Rust just as easily as you can in C; far easier in fact thanks to `cargo vendor`. Cargo won't review them for vulnerabilities though, you'll still have to do that yourself.

It does, the package systems of C evolved alongside the OS, so they are now the OS package managers and also cope with all other language mangers.

C (and C++) has a supply chain. It's called unpaid Linux maintainers.

    > unpaid Linux maintainers

In 2026, I would say most are paid, certainly all of the really important leads. They are employed directly by Linux Foundation, or by a tech giant, like Google, Meta, Amazon, IBM, etc.

Not Linux as in kernel. Linux as in distro. I doubt most of Arch, NixOS, GoboLinux, Slackware maintainers are on FAANG payroll.

RHEL/Fedora SUSE/OpenSuse, ubuntu then?

That is what I was thinking.

"Cargo won't review them for vulnerabilities though, you'll still have to do that yourself."

Cargo is a danger to society. People need to stop using these unsafe and dangerous technology.

There is… standard library and posix standard or other system level libraries, once you learn them you discover you don’t need to auto download a library to convert string to bool that relies on 5 other stupid libraries to work all together.

Lean yet complete standard library is what should be preferred instead of that supply chain, especially in AI era that makes half of them obsolete and redundant.

And a lot of C/C++ library are incredibly mature, so no need to update your code every 3 months just for dependency updates.

Don't use packages you didn't vibecode and audit yourself then. That's the situation C puts you in anyway.

The Rust ecosystem isn't structured for the high friction dependency model the C has. Its structured around nearly frictionless dependencies so its no surprise that dependency trees are very large and frequently changing.

The typical C project has far fewer dependencies than the typical Rust project. Those dependencies are usually individually larger and either maintained by OS maintainers or there is a copy of the code that is built for the project and is readily available for audit. Those copies can't change without direct action.

Its less trouble to setup static analysis, address sanitizer, and similar tools for a C project than it would be to manage local copies of thousands of dependencies for a Rust project.

There's nothing stopping you from ignoring the ecosystem and just using Rust with the stdlib. Remember that the context for this thread is AI-generated code. If the AI is writing it all, the code is effectively free, you can write tens of thousands of lines of it with a single prompt, you can customize it all to your specific use-case, and you can throw it away and have the AI write it again instead of maintaining it. Also as manual programmers we're accustomed to programming being a team sport where you fit in gracefully into the ecosystem and build things with the maintainer and rest of the team in mind, but in the AI world, you can ignore the ecosystem, there is no maintainer (because you throw it away and have the AI write something else when the requirements change), and the rest of the team has all been laid off.

There's a bunch of threads going on simultaneously on HN now about how people often misuse AI by applying rules of thumb learned from doing things as a professional to what they prompt the AI to do, rather than just asking it directly for what you want. This is one of those cases. Many of the rules of thumb of professional programming no longer hold under the radically different economics of AI-driven development.

> If the AI is writing it all, the code is effectively free

Its not even close to free in either $, your own personal time, or calendar time.

My assumption is that people are productive in Rust mainly because of the ecosystem, just like Python programmers are because they can download so many ready-to-use parts. The great mashup languages.

The context of this thread is AI-assisted code. There's no "people" involved, the AI can reconstruct just the parts of the ecosystem that it needs as easily as it can use the ecosystem. That's one of the big sea changes with AI: a lot of the best practices we've developed for coding really focus on creating good user interfaces and abstraction boundaries for coders so we can work in teams and have reasonable PL ergonomics, but when there is no team and no human, many of those considerations disappear.

If the AI replaces the code usually provided by the supply chain, the issues get worse not better.

> Its less trouble to setup static analysis, address sanitizer, and similar tools for a C project than it would be to manage local copies of thousands of dependencies for a Rust project.

It is trivial with Rust to set up asan and friends. You just

  $ RUSTFLAGS=-Zsanitizer=address cargo build -Zbuild-std --target x86_64-unknown-linux-gnu

And you’re off to the races.

This works for your dependencies too. This isn’t C, you don’t need to manage all of those builds individually. That’s what the build system is for.

In C I would install a -dev package or recompile using the package manager. I my opinion, it is deficiency - not an advantage - of the Rust ecosystem that this is managed by a language-level build system.

Rust isn't tied to a language-level build system. You can use plain old rustc to your heart's content. I don't use Cargo for any of my own projects any more.

People tend to use it because they like it.

Reply on news.ycombinator.com