より良いバッテリー

プログラミングにおける永遠の分裂の一つは、標準ライブラリは最小限であるべきか、それとも包括的であるべきかという問いに関するものです。これは間違った問いです。正しい問いは、どのような社会的なアーキテクチャが高品質な標準ライブラリを生み出すかということです。 Pythonは常に、ゆっくりと爆発する「リーキーバッテリー」の例として挙げられますが、これはサイズとは無関係です。Pythonの標準ライブラリの問題はその、ええと、一貫性のない品質です。一部の標準ライブラリモジュールは、言語の命名規則に従っていません！あなたがどのunittestモジュールについて話しているか分かりますよね :-) しかし、それすら間違いではありません。それは実際にはPythonコアの利点です――将来のことをあまり考えずに、機能を早期に利用可能にすることです。それが、CPythonを言語たらしめるossified cAPIに至った方法ですが、データサイエンス革命を支えるPythonに至った方法でもあります。 Goの標準ライブラリも同様に包括的ですが、高く評価されています。Goチームは、標準ライブラリのために適切に設計されたAPIを提供する組織的な能力を持っており、さらにその上を行っています: https://pkg.go.dev/golang.org/x Rustは興味深いケースです。1.0の標準ライブラリAPIは素晴らしいです。コレクションとイテレータは芸術作品です。しかし、現在のチームは既存のAPIを維持し、いくつかのギャップを埋める能力がある一方で、デザイン上の決定を実行する能力は限られているように感じます。golang.org/xが余剰能力を吸収しているのに対し、rust-lang-nurseryは墓場です。 もしかしたら、私は自分の好きな趣味に過剰に依存しているかもしれませんが、Rustが2026年になってもOSからランダムなバイトストリームを取得するAPIを持っていない理由は、それが容易な技術的問題であるにもかかわらず、それを実際に解決するためには、世界的な調整問題であるプログラミング言語という高リスク環境において、複雑な組織アーキテクチャ（もちろん、人々の懐にお金を入れることも含めて）が必要だからだと思われます。