One of the eternal schisms in programming is over whether the standard library should be minimal or encompassing. This is the wrong question. The right one is: Which social architecture creates a high-quality standard library? Python is always brought up as example of leaky batteries exploding in slow motion, but this has nothing to do with size. The problem with Python's stdlib is its uneven quality. Some standard library modules don't follow language naming conventions! But even that is not a mistake — it's Python core's advantage: it makes functionality available early. That's how we ended up with ossified C API which makes CPython the language, but also how Python powered the data scientific revolution.

The Go standard library is similarly encompassing, but held in high regard. Go team has institutional capacity to deliver well-designed API, and then some: golang.org/x. Rust is an interesting case. The 1.0 standard library APIs are brilliant. Collections and iterators are a work of art. But while current team has capacity to preserve existing APIs, capacity to execute design decisions is limited. While golang.org/x captures excess capacity, rust-lang-nursery is a graveyard. The reason for Rust not having an API to get a stream of random bytes from the OS in 2026 is that it requires tricky organizational architecture to solve in a world-wide coordination problem called a programming language.