Better Batteries
Summary
The article explores how the social architecture of programming language communities influences the design and quality of standard libraries, comparing approaches in Python, Go, and Rust.
<header>
<h1>Better Batteries</h1>
<time class="meta" datetime="2026-08-20">Aug 20, 2026</time>
</header>
<p>One of the eternal schisms in programming is over the question of whether the
standard library should be minimal or encompassing. This is the wrong question
to ask. The right one is:</p>
<figure class="blockquote">
<blockquote><p>Which social architecture creates a high-quality standard library?</p>
</blockquote>
</figure>
<p>Python is always brought up as example of leaky batteries exploding in slow
motion, but this has nothing to do with <em>size</em>. The problem with Python’s stdlib
is its, ahem, uneven quality. Some standard library modules don’t follow
language naming conventions! You know which <code>unittest</code> module I am talking about
:-)</p>
<p>But even that is not a mistake. It’s actually Python core’s advantage — that
it makes functionality available early, not thinking about the future too much.
That’s how we ended up with ossified cAPI which makes CPython the language, but
that is <em>also</em> how we ended up with Python powering data scientific revolution.</p>
<p>The Go standard library is similarly encompassing, but it is held in a high
regard. Go team has institutional capacity to deliver well-designed API for the
standard library, and then some: <a href="https://pkg.go.dev/golang.org/x" class="display url">https://pkg.go.dev/golang.org/x</a></p>
<p>Rust is an interesting case. The 1.0 standard library APIs are brilliant.
Collections and iterators are a work of art. But it also feels that, while the
current team has the capacity to preserve existing APIs and fill in <em>some</em> gaps,
the capacity to execute design decisions is limited. While <code>golang.org/x</code>
captures excess capacity, <code>rust-lang-nursery</code> is a graveyard. Maybe I am
over-indexing on
<a href="https://matklad.github.io/2023/01/04/on-random-numbers.html#True-Randomness">my favorite hobby-horse</a>,
but it seems that the reason for Rust not having an API to get a stream of
random bytes from the OS in 2026 is that, while it is an easy technical problem,
it requires tricky organization architecture (including getting money in
peoples’ pockets, of course) to actually get solved in the high-stakes
environment of a world-wide coordination problem called a programming language.</p>
View Cached Full Text
Cached at: 08/21/26, 03:34 AM
# Better Batteries
Source: [https://matklad.github.io/2026/08/20/better-batteries.html](https://matklad.github.io/2026/08/20/better-batteries.html)
Aug 20, 2026One of the eternal schisms in programming is over the question of whether the standard library should be minimal or encompassing\. This is the wrong question 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 motion, but this has nothing to do with*size*\. The problem with Python’s stdlib is its, ahem, uneven quality\. Some standard library modules don’t follow language naming conventions\! You know which`unittest`module I am talking about :\-\)
But even that is not a mistake\. It’s actually Python core’s advantage — that it makes functionality available early, not thinking about the future too much\. That’s how we ended up with ossified cAPI which makes CPython the language, but 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 regard\. Go team has institutional capacity to deliver well\-designed API for the standard library, and then some:[https://pkg\.go\.dev/golang\.org/x](https://pkg.go.dev/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 it also feels that, while the current team has the capacity to preserve existing APIs and fill in*some*gaps, the capacity to execute design decisions is limited\. While`golang\.org/x`captures excess capacity,`rust\-lang\-nursery`is a graveyard\. Maybe I am over\-indexing on[my favorite hobby\-horse](https://matklad.github.io/2023/01/04/on-random-numbers.html#True-Randomness), but it seems that the reason for Rust not having an API to get a stream of random bytes from the OS in 2026 is that, while it is an easy technical problem, it requires tricky organization architecture \(including getting money in peoples’ pockets, of course\) to actually get solved in the high\-stakes environment of a world\-wide coordination problem called a programming language\.
Similar Articles
Python or Rust? Coding with local LLMs
A discussion post asking whether Rust or Python is better for coding with local LLMs, exploring whether Rust's compiler feedback helps compensate for weaker small models running on consumer hardware.
Performance of Rust language
This talk analyzes Rust's performance strengths and weaknesses compared to C++, providing benchmarks and best practices. Slides and reading materials are available.
Why do common Rust packages depend on C code? (2023)
The article explores why many common Rust packages have dependencies on C code, likely discussing technical reasons and implications for the ecosystem.
Named and Optional Arguments are Awesome
The article critiques Rust's lack of named and optional arguments, compares implementations in Dart, C#, TypeScript, and Python, and proposes potential future solutions for Rust.
Quoting Mitchell Hashimoto
Mitchell Hashimoto comments on the increasing fungibility of programming languages, using Bun's rewrite from Zig to Rust as an example, suggesting that languages are no longer a source of lock-in.