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