高速でハードなコード

高速でハードなコード Twitterのミームの一つに「プログラミングはもう解決した」というものがある。それがどの程度解決したかは分からないが、一つだけ非常に明確なことがある。言語に慣れるという行為はもはや重要ではなくなり、人間にとって重要だった摩擦の一部はエージェントにとっては重要ではなくなった。その結果、LLMは言語の選択を以前よりもはるかに重要でなくしている。もし選択が気に入らなければ、別の言語で書き直すことができ、プログラマーであるあなた自身が全く慣れていない言語を選ぶようにさせることもできる。これはひいては、人々が言語のマーケティングに基づいて、より多く選択できるようになり、そして実際にそうしていることを意味する。長年のRustプログラマーとして、以前は選ばなかったであろう人々が今Rustコードを出荷しているのを見るのは非常に興味深かった。私はこれを、最近の2つの雰囲気の変化に少なくとも一部起因すると考えている。高速なソフトウェアを求める声が多くなり、LLMが振る舞いを後退させることなくコードを最適化することに長けているという話だ。Mitchell Hashimoto、Charlie Marsh、Jarred Sumner、Daniel Lemireといった人々は常に高速で高性能なソフトウェアへのある種の執着を抱いており、彼らは皆、エージェントがコードを書くことに対して受容的でもある。結果として、あるいは無関係に、他の人々も今加わっている。なぜなら、オートリサーチのようなものでは、必ずしもすべてのトリックを知っている必要はなく、エージェントにそれを任せればよいからだ。もちろん、知識は大いに役立つ！ 周りを見渡せば、高速で小規模であることを望むプロジェクトはたくさんあり、それらはますます「ハードな言語」を選んでいる。そしてRustだけが恩恵を受けているわけではない。Zigでさえ、その作成者やコアコミュニティの一部がAI全般に対してかなり否定的であるにもかかわらず、そうだ。例えば、Cloudflareの新しいArtifactsサービスは、純粋なZig Gitプロトコルエンジンを使用しており、約100 KBのWebAssemblyモジュールにコンパイルされている。Vercelは、小さくて高速であると宣伝されているZigコーディングエージェントfxをリリースした。私の知る限り、これらのプロジェクトはすべてLLMによって支援されている。しかし、人々が一般的でない言語を選んでいるだけでなく、ますます「はるかにハードな」テクノロジーを扱っていることにも注目すべきだ。突然、DWARFファイル、eBPF、カスタムネットワークドライバ、カスタム暗号、そして非常に古いコンピューティングハードウェアで、本当に印象的なことをしている人々を目にするようになった。これらの多くは、以前は多くの開発者にとって手の届かないものだった。場合によっては（例えば暗号）、知っている人々によって意図的にゲートキーピングされていたため、遠ざけられていたことさえあった。だから、世界にはより多くの「スロップ」（不完全さ、または無駄）が生まれるかもしれないが、高速で小規模なものを望む開発者も増えるかもしれない。 このエントリは ai, programming, thoughts としてタグ付けされました コピー / Markdown表示 © 2026 Armin Ronacher による著作権。 コンテンツはクリエイティブ・コモンズ 表示-非営利 4.0 国際ライセンスの下でライセンスされています。 メール、bluesky、x、またはgithubで連絡してください。 GitHubで私をスポンサーすることができます。 詳細：インプリント & AI透明性。 atom / RSSで購読。 配色：自動、ライト、ダーク。