Rustへの書き換えの現実：パフォーマンス、失敗、そして2026年の真実
Rewriting in Rust
Rustへの書き換え（RIIR）は本当に「爆速」なのか？JetBrainsのブログで、cot.rsのメンテナーであるMateusz Maćkowski氏とMarek Grzelak氏が、実際のプロジェクトの事例を基に、パフォーマンス向上の実態、新たに生じるバグ、Prismaやcurl/hyperなどの失敗例、バイナリサイズやライセンスの問題、そしてLinuxカーネルやWindowsでの採用がもたらす意義を解説。成功の鍵は全面書き換えよりも段階的な導入にあると説く。
Rustを全面的に書き換えることをデフォルトの回答にすることは、6ヶ月遅れで出荷され、すでに修正済みのバグを持ち込む2年間の書き換えプロジェクトに終わる方法だ。
HNでの議論
61- collinfunk
注記：私はGNU coreutilsの共同メンテナです。そのことが私の意見を関連性のあるものにするのか、偏ったものにするのか、あるいはその両方なのかは、皆さんが判断してください。:)
この記事でベンチマークの方法論を文書化してほしかったです。少なくとも、示されたベンチマークに基づいて結論を急がないように読者に注意を促してほしかったです。
GNUの'sort'のパフォーマンスは、使用するロケール、入力、--buffer-sizeや--parallelオプションに与える引数によって劇的に変わります。GNUの'sort'はデフォルトで使用するスレッド数に関してかなり控えめで、私の経験ではuutilsよりもはるかに控えめです。これは、'sort'に多くのスレッドを投入すると高速になるかもしれませんが（あるいはならないかもしれません）、メモリ不足のリスクもあるからです。これはuutilsの問題で、外部ソートを使うべきタイミングの判断が苦手です：
$ export LC_ALL=C
$ for i in {a..z}; do yes $i | head -n $(numfmt --from=iec 512M) | tr -d '\n' >> input; done
$ time sort input > /dev/null
real 0m24.245s
user 0m0.896s
sys 0m19.161s
同じコマンドを最新のuutilsコミットを'make PROFILE=release'でコンパイルして実行すると：
$ time uu-sort input > /dev/null
Killed uu-sort input > /dev/null
real 2m53.560s
user 1m40.634s
sys 0m59.847s
プロセスはOOMキラーによって強制終了されます。これはおそらく、uutilsの'sort'がGNUの'sort'が使う1スレッドではなく18スレッドを使うことを決定するためです。方法論や引用なしにベンチマークが投げ出されるのは少しイライラします。なぜなら、それらはしばしば疑いなく信頼されるからです。これらは可能性があります[…]
- kmaitreys
この話題は最近、分極化した反応を引き起こすような含意を持つようになりました。人々はその言語に「うんざり」しているようで、Bunの書き換えのような出来事は、特に現在のLLMに夢中な時代には助けになっていません。
そうした中で、この言語があまり普及していない分野（科学/数値プログラミング）で働く者として、私自身の経験を共有させてください。数年前、Pythonを高速化しようとして疲れ果てた後、シミュレーションコードを書くための言語を探していました。私の分野ではFortran（そしてC/C++）が何十年もの間、定番の選択肢でしたが、私はモダンな言語を試してみたかったのです。Juliaを試しましたが、ワークフローが自然に感じられませんでした。また、デフォルトではAOTコンパイルもできませんでした。Rustは第二の選択肢でしたが、その型システム/設計、表現力、ツーリング（rust-analyzer）に惹かれました。私はたくさんRustでコードを書いてきましたが、本当に書いていて楽しいです。借用チェッカーは、科学コードを書くときの99%のケースでは問題になりません。そして、問題になる場合（自己参照的なデータ構造）でも、アリーナ（または同等のもの）を使えばいいだけです。C/Fortranとの相互運用性は素晴らしく、ODEや疎行列を解くような一般的なもののために、その上に独自の抽象化を構築するのも簡単です。
そしてもちろん、速度、メモリ安全性、そして並列化をこれほど簡単にできること（rayonは魔法のようです）もありますが、それらが私を惹きつけたものではなかったと感じています。その言語はただ書いていて楽しいものでした。
- ameliaquining
この投稿は、一度に全部書き換えるのではなく、段階的に書き換えることを提唱しています。2000年にJoelが言ったように、そして今日に至るまで誰もがずっと言い続けているように。しかし実際には、人々はこれを実行していません。特にC以外の言語からの書き換えの場合、完全な書き換えの方が段階的な書き換えよりもはるかに一般的です。Linux、Windows、Firefoxのような注目すべき例外は、あまりにも巨大で古いコードベースであり、明らかにゼロから書き直すことはできません。ゼロからの書き換えが選択肢にある場合、それは選ばれる傾向があります。
その理由はかなり単純です：別の言語（特にCでない場合）からRustへコードベースを段階的に移植することは、非常に不快な経験です。なぜなら、相互運用ツールが十分に良くなく、そのほとんどをそれとの戦いに費やすことになるからです。C++からの書き換えの場合を考えてみましょう。最も単純なケースでは、bindgenとcbindgenを使用しますが、これらは両言語のextern "C"関数でのみ機能します。つまり、実質的に各APIをまず慣用的なC++からC-in-C++に書き換え、次にC-in-Rustに翻訳し、さらに慣用的なRustに書き換える必要があります。そして、次のAPIについても同じことを繰り返します。そして、それを続けます。ほとんどのプログラマーが「もういい、Joelが何と言おうと気にしない。少なくとも全部書き換えるなら、何でも呼び出せる一つの言語でやることになる」と言い出すのにそれほど時間はかからないでしょう。cxxとautocxxは状況を適度に改善しますが、それでもAPIの語彙が貧弱で、同様の問題が残り、まだ[…]
- tonyedgecombe
一瞬、JetBrainsがツールをRustで書き直していて、パフォーマンスが向上するのかと思いました。
- joshdavham
JetBrainsがIntelliJを高速化してくれたら嬉しいです。昨年、Javaを専門に書く新しい仕事を始めましたが、その時までIDEがそんなに遅いとは知りませんでした。
私の会社は新品の高性能なMacBook Proをくれましたが、それでもIntelliJを処理しきれないことがあります...