/bin/true (was Performance concerns when heavily used in scripts ?)

One of the significant concerns about number of dependencies is the vulnerability to supply chain attacks, and I think small dependencies actually make that worse, even if the number remains constant.

In C++, if I want something very simple like a circular buffer class, I might find it as part of Boost. That's a huge dependency for such a little feature, which does have some drawbacks. But because it's huge I can be confident there are many developers working on the project. There are review processes, and if one developer tries to slip in something naughty then there's a reasonable chance another developer will spot it before it's released. Security researchers will be running their tools over it. If a vulnerability is reported, there are responsible maintainers who will respond promptly.

If I want the same in Rust, I'll probably find a library that is just one random guy on GitHub. A lot of the code has probably been reviewed by exactly zero other people. There is nothing to mitigate against that developer being malicious, or having their GitHub account compromised, or carelessly accepting a pull request from another random user. They might ignore a vulnerability report for months. They're lacking all the processes and shared responsibility that comes from being in a large project.

I'd agree the huge dependencies will probably have more accidental vulnerabilities, because the sheer quantity of code will outweigh the improved review processes - but Rust's memory safety should already mitigate a lot of that risk, compared to C/C++. That means deliberate backdoors are a relatively greater risk, even before attackers realise there aren't enough buffer overflows and use-after-frees left for them to exploit and they'll have to shift towards more supply chain attacks.

I think the benefit of the c++ approach is that maintenance for the libraries is generally less concerning. Group ownership of libraries feels a lot safer than tons of tenuously owned and maintained libraries. You don't need to put everything in a single repo or dependency to make this work of course but if you do put everything in one repo then that ownership structure is forced. And to be clear there are many examples of the above approach in the rust ecosystem as well. It's just difficult to ensure all of your deps originate from such entities as there are such deep layers of transitive dependencies, which is again less likely in the c++ ecosystem.

I hope to see this situation improve over time as larger organizations continue to adopt rust and place more strict rules on allowable dependencies.