A Big Standard Library Is Overkill · Dmitrii Aleksandrov
A Big Standard Library Is Overkill
Posted on Jul 2, 2026
2 mins
Rust<br>Tech
To solve the problems of “supply chain security” and “relying on a random person<br>in Nebraska”, it’s enough to maintain our libraries of interest under the same<br>“trusted” org that maintains the stdlib.<br>Actually including all that code in the stdlib is unnecessary and harmful,<br>because it imposes strict compatibility guarantees and keeps us stuck with an<br>old API even after a better one is discovered. See any standard datetime library<br>or any of Python’s “dead batteries”.<br>Examples of doing this right:<br>golang.org/x/...<br>repositories.<br>Several prominent “third-party” Rust crates (such as<br>libc<br>rand<br>, and<br>regex<br>) have been moved under the<br>official rust-lang<br>org.<br>The raw number of dependencies in a project is<br>meaningless<br>Having to specify your dependencies in a manifest and download them over the<br>internet is not a problem in itself.<br>Ecosystem fragmentation is a problem, but only for common, fundamental<br>interfaces. Those should be included in the standard library.<br>Relying on arbitrary third parties is a problem, but it can be solved without<br>pushing everything into the standard library.<br>One other solution is an audit database like<br>cargo-vet<br>and<br>cargo-crev<br>, where you can “delegate”<br>and automatically trust someone else’s audits. You can trust one auditor instead<br>of many individual authors.<br>Related reading
A related “supply chain” thread that prompted this<br>post<br>LetsBeRealAboutDependencies
Comments