Better Batteries

One of the eternal schisms in programming is over the question of whether the<br>standard library should be minimal or encompassing. This is the wrong question<br>to ask. 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<br>motion, but this has nothing to do with size. The problem with Python’s stdlib<br>is its, ahem, uneven quality. Some standard library modules don’t follow<br>language naming conventions! You know which unittest module I am talking about<br>:-)

But even that is not a mistake. It’s actually Python core’s advantage — that<br>it makes functionality available early, not thinking about the future too much.<br>That’s how we ended up with ossified cAPI which makes CPython the language, but<br>that is also how we ended up with Python powering data scientific revolution.

The Go standard library is similarly encompassing, but it is held in a high<br>regard. Go team has institutional capacity to deliver well-designed API for the<br>standard library, and then some: https://pkg.go.dev/golang.org/x.

Rust is an interesting case. The 1.0 standard library APIs are brilliant.<br>Collections and iterators are a work of art. But it also feels that, while the<br>current team has the capacity to preserve existing APIs and fill in some gaps,<br>the capacity to execute design decisions is limited. While golang.org/x<br>captures excess capacity, rust-lang-nursery is a graveyard. Maybe I am<br>over-indexing on<br>my favorite hobby-horse,<br>but it seems that the reason for Rust not having an API to get a stream of<br>random bytes from the OS in 2026 is that, while it is an easy technical problem,<br>it requires tricky organization architecture (including getting money in<br>peoples’ pockets, of course) to actually get solved in the high-stakes<br>environment of a world-wide coordination problem called a programming language.