Rustに関する本格的な執筆をcorrode blogに移したので、ここでは少し気楽に、既存のソフトウェアでRustを使うことをめぐる最近の議論について、個人的な考えを書いてみたいと思います。

話題になっている2つのプロジェクトは、git（カーネルのスレッド、Hacker Newsでの議論）と、最近Rustで書き直されたRust版coreutilsで、後者はUbuntu 25.10 Quizzical Quokkaに搭載される予定です。

この記事を書くきっかけになったのは、X（Twitter）での議論と、「Are We Chasing Language Hype Over Solving Real Problems?（私たちは本当の問題解決よりも言語の流行を追いかけているのか？）」というタイトルのブログ記事です。

どちらのケースでも、著者はRustを選ぶ動機について推測していますが、実際にチームのRust本番導入を支援している立場からすると、そうした意見は……正直、笑ってしまいます。

corrodeを始めた当初は、「Rustは真面目な用途では使われていない」とよく言われました。クライアントワークを通じて本番環境での事例は知っていましたが、公開されている情報はほとんどありませんでした。そこで、企業が実際に現実のアプリケーションでRustを選んでいることを示すために、ポッドキャスト『Rust in Production』を始めました。ところが、人は間違いを認めたがらないもので、今ではその陰謀論は「巨大なRust（Big Rust）が世界征服を企んでいる」という話に姿を変えています。😆

ブログ記事とXのスレッドで挙げられていた主張をいくつか見て、それらがいかに簡単に反証できるかを確認してみましょう。

「GNU Core Utilsはその歴史の中で、基本的に重大なセキュリティ脆弱性を一度も抱えたことがない」

そうであればよいのですが。CVEをざっと検索するだけで、数十年にわたってバッファオーバーフローやパストラバーサルを含む複数のセキュリティ問題が見つかります。つい数か月前にも、sortでヒープバッファのアンダーリードが発見されており、攻撃者が細工した入力ストリームを送ることで機密データが漏洩する可能性があるものでした。

GNU coreutilsは世界で最も広く使われているソフトウェアパッケージの一つで、数十億の環境にインストールされ、何百人（何千人？）もの開発者がコードに目を通しています。それでも脆弱性は起こります。正確で安全なCのコードを書くのは簡単ではありません。いえ、どれだけ慎重で厳格にやっても、簡単にはならないのです。

lsは5,000行にもなります（ソースコードを見てみてください）。ファイル名とメタデータを表示するだけでこれだけのコード量です。攻撃面もそれだけ大きくなります！

「RustはせいぜいCの性能に並ぶのが関の山で、通常はもっと遅い」

Trifectaによる研究では、場合によってはCよりも高速なRustコードを書けることが示されています。特に並行処理を伴うワークロードで、しかもメモリ安全性を保証したままです。安全なCコードを書くのが難しいと思うなら、安全な並行Cコードを書くことに挑戦してみてください！

まさにここでRustが輝きます。セキュリティ上の問題を心配することなく、驚くほどの並列化を実現できます。しかも、コードをunsafeブロックだらけにする必要はありません。Oxideについて語ったSteve Klabnik氏の最近のトークを見てみてください。同氏のブートローダーとプリエンプティブなマルチタスクOSであるhubrisは、どちらもかなり中核的なシステムコードですが、unsafeコードはそれぞれわずか5%しか含まれていません。Rustなら、unsafeを一切使わずに大規模なコードベースを書くことも可能です。

些細な例ですが、ある日思い立ってcatをRustで書き直してみたところ、私の手元ではGNUのcatより3倍高速になりました。詳しくはこちらの記事で読めます。やったことはspliceを使ってデータをコピーしただけで、メモリコピーを1回分節約したに過ぎません。性能は言語だけで決まるのではなく、どのようなアルゴリズムやシステムコールを使うかにも左右されます。

Rustの強みを活かせば、Cの性能に並ぶことは可能です。少なくとも、それを妨げる技術的な制約はありません。個人的には、メモリ安全性のバグを埋め込む心配がない分、Rustではより積極的に最適化しようという気になれます。私だけではないようです。

「業界では必要性よりも目新しさを評価している」

これは、成功している企業の大半（GoogleやMetaなど）が、最先端の言語ではなく、枯れた技術スタックを主に使っているという事実を無視しています。そうした企業は巨大なコードベースを抱えており、すべてを最新の流行言語で書き直す余裕はありません。それでも、新しいコンポーネントにRustを使ったり、既存のものを徐々に書き換えたりすることに価値を見出しています。なぜなら、セキュリティ脆弱性の70%はメモリ安全性の問題であり、その修正には莫大なコストがかかるからです。もし言語を切り替えずに済むなら、そうしたいはずです。

そもそもRustはもう決して新しい言語ではありません。Rust 1.0がリリースされてから10年以上が経っています。業界の動きはゆっくりですが、そこまで遅くはありません。どれほど多くの確立された企業が、わざわざ発表することもなく、「目新しさ」とも考えずにRustを使っているかを知れば、驚くはずです。

「100%仕組まれたものだ」

Xのスレッドでは、複数の人がこれを開発者がより良いツールを選んだ結果ではなく、何らかの組織的な陰謀だと信じ込んでいました。一方で、gitやcoreutilsのメンテナ自身は、誰もが見られる公開の場でその動機を率直に語っています。

「彼らはCを置き換え／消し去ろうとしている。そんなことは起こらない」

彼らの言うとおりです。Cがすぐになくなることはありません。世の中には膨大な量のC/C++コードが存在しており、すべてをRustで書き直すのは現実的ではありません。良いニュースは、C/C++のコードをRustで少しずつ、一つのコンポーネントずつ書き換えていけることです。gitのメンテナが計画しているのも、まさに新しいコンポーネントにRustを使うというやり方です。

「GNUライセンスのソフトウェアをMITライセンスのソフトウェアに書き換えている」

Rustを使ったからといって、GPLや好きなライセンスでコードを公開できなくなるわけではありません。Git自体はGPLのままですし、多くのRustプロジェクトもMITだけでなく様々なライセンスを使っています。ライセンスへの不安は、オープンソースのライセンスの仕組みを理解していない人によって持ち出されることが多く、単なるFUD（不安を煽る言説）である場合もあります。

MITライセンスのコードはGPLのコードと互換性がありますし、同じプロジェクト内で両者を問題なく併用できます。ただ、最終的な成果物（ユーザーに提供するもの、つまりバイナリの実行ファイル）は、GPLの伝播性によりGPLの適用を受けるというだけです。

「ただ開発者が退屈していて、ピカピカの新しい言語を触りたいだけだ」

Cプロジェクトのベテランメンテナは引退しつつあり、空き時間を使ってレガシーコードを保守するためだけにCを学ぼうという新しい開発者は減っています。Cの開発者は実質的に絶滅しつつあります。新しい開発者はモダンな言語で働きたいと思っていますが、無理もありません。40年前のCOBOLのコードベースや古いPerlスクリプトを保守したいと思いますか？ 私たちは先に進まなければなりません。

「既存のツールを書き直すのではなく、まったく新しいものを一から作ればいいのでは？」

そう簡単な話ではありません。コードは物語の一部に過ぎないのです。残りの部分は、エコシステム、ツール群、統合、ドキュメント、そしてユーザーベースです。これらすべてを築くには何年もかかります。ユーザーはワークフローを変えたがらないため、差し替え可能な置換を求めています。どれほど粗野で古臭く見えても、実証済みのインターフェースやAPIには大きな価値があります。

とはいえ、もちろんRustで新しいツールも次々と作られています。

「彼らは問題を実際に解決する方法を知らず、ただ流行を追っているだけだ」

何年も、時には何十年もこれらのプロジェクトに取り組み、その課題を誰よりも理解しているメンテナたちの技術的な専門性を軽視するにもほどがあります。

もし彼らがただ流行を追っているだけなら、そもそもこうしたプロジェクトを保守したりはしないでしょう！ 彼らは世界で最も経験豊富な開発者の一部であり、それなのに人々は彼らに仕事のやり方を指図しようとするのです。

「ソフトウェアに蔓延する“woke mind virus（意識高い系ウイルス）”の一部だ」

メモリ安全性が政治的な陰謀だと考えるなんて想像できますか。どうやらバッファオーバーフローを防ぐことが、今では思想的な立場とみなされるようです。これに一番近いのは、政府のソフトウェアにメモリセーフな言語を推奨し、連邦資金を受けるソフトウェアにメモリ安全性を義務付けるというホワイトハウスの技術報告書ですが、これは至極まっとうな提言です。

結論

まだまだ続けられますが、言いたいことは伝わったと思います。

Rustに真摯に向き合った人なら、メモリ安全性、並行性、そして保守性の面でRustが優位性を持つことを知っています。これは流行を追うことではなく、ソフトウェアの品質への長期的な投資なのです。日々ますます多くの企業がRustの導入に成功するにつれ、Rustは多くの新規プロジェクトで次第にデフォルトの選択肢になりつつあります。

Rustを本番環境で使うことについてもっと知りたい方は、もう一つのブログをチェックするか、ポッドキャスト「Rust in Production」を聴いてみてください。

あ、それから、もしこうした意見を投稿している知り合いがいたら、議論するのはやめて、この記事へのリンクを送ってあげてください。