> Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro.
You're comparing apples to oranges. Most C/C++ software in business use isn't pulling its dependencies from distro PMs, it's pulling them from some monstrous dark web of Visual Studio projects and opaque git repos. And on the other hand, Rust software that's distributed in distro PMs uses distro dependencies like any other package. Equally, as you note, the reverse exists. None of this tells us very much about Rust or C/C++ as languages.
> Rust projects tend to statically link random code from hundreds of dependencies nobody ever reads
'Tend to' is doing a lot of heavy lifting in that sentence, and doesn't seem to be based on very much more than 'I saw it a few times'. Well, I've seen my share of nightmarish C++ dependency trees. Is that a good argument against C++? Not really.
You're picking up on real issues - unnecessary and untrusted dependencies - except you're then erroneously drawing some imagined line in the sand where Rust bad and C/C++ good, which is where a rational argument seems to collapse into vibes. On the whole, there's a lot more C++ projects out there guilty of this than Rust projects.
> Sure, you can do it right with Rust. But you can also write good code with C/C++.
You can hammer a nail with a broom, but that doesn't make it the best tool for the job. The safety advantages of Rust can't just be hand-waved away. C is a fine programming language when safety is less of an issue. If you're writing a Nintendo emulator, sure, C, why not. If you're writing business logic that handles health data, maybe not.