Rustに関する私の仕事としての執筆はcorrode blogに移行したため、ここではもう少しカジュアルに、既存のソフトウェアでRustを使うことをめぐる最近の議論について個人的な考えを共有したいと思います。

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

この記事を書くきっかけとなったのは、Twitterでの議論と、「Are We Chasing Language Hype Over Solving Real Problems?」というタイトルのブログ投稿です。

どちらのケースでも、著者たちはRustを選ぶ動機について憶測を巡らせていますが、チームがRustをプロダクションで使えるよう支援している立場からすると、そうした意見は…正直、笑ってしまいます。

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

ブログ投稿やTwitterのスレッドでなされた主張のいくつかを見て、それらがいかに簡単に論破できるか見ていきましょう。

「GNU Core Utilsは、その存在のほぼ全期間を通じて、重大なセキュリティ脆弱性を一度も抱えたことがない」

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

GNU coreutilsは世界で最も広く使われているソフトウェアパッケージの一つで、数十億ものインストールがあり、何百人（何千人？）もの開発者がコードに目を通しています。それでも脆弱性は起きます。いいえ、正確で安全なCのコードを書くのは簡単ではありません。たとえ細心の注意を払い、規律を守ったとしても、です。

lsは5000行もあります（ソースコードをご覧ください）。ファイル名とメタデータを表示するだけにしては膨大なコード量であり、攻撃対象領域も大きいのです！

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

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

そこでRustが真価を発揮します。セキュリティの問題を心配することなく、驚くほどの並列化を実現できます。しかも、コードをunsafeブロックだらけにする必要はありません。Oxideに関するSteve Klabnikの最近のトークをご覧ください。そこでは、彼らのブートローダーとプリエンプティブなマルチタスクOSであるhubris — どちらもかなりコアなシステムコードですが — それぞれunsafeコードはわずか5%しか含まれていないことが示されています。大規模なコードベースを、まったくunsafeコードなしで書くことも可能なのです。

些細な例ですが、ある日Rustでcatを書き直してみました。結果は、私のマシンではGNUのcatより3倍高速でした。詳細はこちらの投稿で読めます。やったことはspliceを使ってデータをコピーしただけで、これによりメモリコピーが1回分削減されます。パフォーマンスは言語だけに依存するのではなく、使うアルゴリズムやシステムコールにも左右されるのです。

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

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

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

しかも、Rustはもはや決して新しいわけではありません。Rust 1.0は10年以上前にリリースされています！ 業界の動きは遅いですが、そこまで遅いわけでもありません。どれだけ多くの老舗企業が、わざわざ発表することもなく、「目新しさ」とも考えずにRustを使っているか知れば驚くでしょう。

「100%仕組まれている」

Twitterのスレッドでは複数の人が、これを開発者がより良いツールを選んだ結果ではなく、何らかの組織的な壮大な計画だと確信していましたが、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 in Productionポッドキャストを聴いてみてください。

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