Rustコンパイラ（そして私にとって）2026年はエキサイティングな年

2026年はRustコンパイラ（そして私）にとってエキサイティングな年

皆さんもすでにお気づきかもしれませんが、2026年はRustコンパイラにとって特別な年になりそうです。多くのことが進行しており、私がこの記事を書き始めた後にも発表されたものがありますが、まだあまり知られていないこともたくさんあります。ここでは、個人的に興味深いと感じるいくつかの事柄を共有したいと思います。

少し背景を説明すると、今年起こっているのは、複数の異なるイニシアチブが同時に最終段階を迎えているということです。つまり、2026年が特別なのではなく、長年の投資が実を結び始める年なのです。

次世代ソルバー 🔗

おそらく最も大きな出来事は、次世代トレイトソルバーでしょう。これは型システムのかなりの部分を再実装するもので、非常に長い間（様々な形で約10年間）開発が進められてきました。これにより、多くの健全性に関するバグが修正され、多くの機能や長年の問題に対する修正が可能になります。

これがコンパイラにとってどれほど大きな意味を持つかを過小評価するのは簡単です。この作業は、多くのコンパイラ開発者が長年夢見てきた主要な技術的負債を解消するものです。また、型システムに関する新鮮で深い理解を持つ多くの人々が、新しいことに取り組むための時間を確保できるようになります。これにより、言語の多くの一般的な問題点、たとえ些細に見えたり無関係に見えたりするものでさえも、解決への道が開かれます。これには、async Rustにおける大きな問題や、impl Traitの様々な制限に対する解決策が含まれます。

Polonius 🔗

もう一つの大きな進展は、Polonius、新しい借用チェッカーの実装です。これもまた、長い時間をかけて開発されてきました。これにより、より多くのコードがコンパイルできるようになり、いくつかの関連機能（将来的には内部参照も含まれるかもしれません）のブロックが解除されます。コンパイラへの影響は新しいソルバーほど大きくはありませんが、それでも非常に重要な進歩です。

パフォーマンス 🔗

私の主な関心分野はコンパイラパフォーマンスですが、ここでもかなりの進展が見られます。1〜2年ほどの停滞（少なくとも結果の面では）の後、突然多くのことが同時に進行し始めました。あまりにも多くのことがあるため、すべてを記憶するのが難しいほどですが、覚えている限りでは以下の通りです。

並列フロントエンドの安定化が近い 🔗

これは非常に古いイニシアチブで、数年間は多くの不明確なブロッカーにより休止されていました。数年前に新しいコントリビューターである@SparrowLiによって開発が再開され、その後も多くの人々がこの取り組みに貢献してきました。

長年にわたり、これは巨大な「パンドラの箱」であることが判明しました。設計に本当に満足している人はほとんどいないように感じます。しかし、近い将来、より良い代替案は見当たらないため、煩雑で厄介な問題をひたすら解決していくというアプローチが取られています。

現在のプロジェクト目標は@petrochenkovによって推進されており、安定化に近づいています。

LLVMが高速化 🔗

LLVM 23は、パフォーマンスにおいて明白かつ予想外の大きな改善をもたらしました。長らく、LLVMのアップグレードはrustcのパフォーマンスにとってそれほど大きな恩恵をもたらしていませんでした。これはLLVM 10のアップグレード後に変化し、10%の大幅な後退を引き起こしました。LLVMの現在のリード開発者である@nikicは、彼のブログ記事「Make LLVM fast again」でこの件に言及しました。この記事では、rustcで使用されているものに触発されたLLVMのパフォーマンスを追跡するシステムも紹介されています。

それ以来、LLVMはパフォーマンスの回帰を早期に検出できるようになり、rustcでのアップグレードの結果は「あまり悪くない」から「いくらか混合」、そして「注意点はあるものの、ほとんどが肯定的」へと変化しました。最後の「肯定的」だったのはLLVM 22で、icountベンチマークではグリーンでしたが、壁時計時間ではほぼすべてレッドでした。

LLVM 23は、ほぼ完全に肯定的です。LLVMの開発はそれほど追っていませんが、私の理解では、これはパフォーマンスを低下させる機能に取り組むのではなく、実際に最適化するための作業が増えたためです。最近の改善は、新しい最適化（ブートストラップ中のコンパイラを最適化するのに役立ちます）と、LLVM自体の高速化の両方から来ています。

大量のパフォーマンス改善（マイクロ最適化）が着地 🔗

過去数ヶ月間、コンパイラパフォーマンスは着実に改善を続けています。単一の説明があるわけではなく、新しいコントリビューターの参加、既存コントリビューターによるパフォーマンス作業の増加、ツールの改善、アーキテクチャのクリーンアップによる新しい機会の解放などが組み合わさった結果です。

この分野でより多くの人々が働くようになり、アイデアが互いに影響し合い、PRからインスピレーションを得て関連する作業を試みるなど、多くのクロスモチベーションが見られます。

また、リグレッションの管理、トリアージ、対処が格段に上手くなったと感じています。これはツールの投資の一部ですが、プロセスや社会構造によるところも大きいです。この分野の大きな進展は、ツリーオペレーションとパフォーマンスのトリアージの連携であり、特に@JonathanBrouwerによって代表されています。

これは、マージを管理する人々がパフォーマンスへの影響を直接トリアージすることを意味します。これは応答時間を短縮するために重要ですが、他の理由でも役立ちます。パフォーマンスへの影響は、例えばPRをロールアップにまとめる方法に影響を与えます。Conwayの法則が依然として法則であることが判明しました。

また、測定結果の解釈やリグレッションの診断を手伝うことも非常に楽しんでいます。長年毎日結果を見ている人からの数行のアドバイスが、リグレッションの解決に大きく貢献することがよくあります。

全体として、コンパイル時間の懸念が、これまで以上に開発に統合されていると感じています。

Moveの除去 🔗

これは今年初めにどこからともなく現れたように見え、非常に興味深いです。@Amanieuは、LLVMが最適化に苦労するコピーをコンパイラが除去できるようにするMIR最適化パスを提案しました。これはコンパイル時間と実行時間の両方を高速化します。

これは、RustコンパイラがLLVMよりもRust固有の情報を持っているため、MIRで実装する方が理にかなっているパスの1つです。なぜなら、RustではC(++)よりも多くのムーブが発生する傾向があり、C(++)はLLVMの主なターゲットだからです。

ポリモーフィゼーション 🔗

これは特に私の心を惹かれるもので、長年この取り組みを追ってきました。ポリモーフィゼーションは、私たちができる最も影響力のあるコンパイラパフォーマンス最適化の1つですが、残念ながら実装が非常に難しいです。

これは私が知る限り3番目の実験になります。今回は以前のものとは少し異なり、Swiftの同様のメカニズムに触発されています。

違いは、元のポリモーフィゼーションは重複または冗長なモノモーフィゼーションを回避することのみを目的としており、実行時間への影響がない純粋なコンパイル時最適化であるのに対し、Swiftスタイルのものはすべてをポリモーフィズし、ジェネリックパラメータのレイアウトを引数として渡すことを意図しています。これには実行時コストがかかるため、コンパイラフラグで調整できるものになります。

私の理解が最新であれば、次世代ソルバーは以前意図されていた方法でのポリモーフィゼーションも可能にするでしょう。いずれにせよ、両方のオプションは同じ問題に直面するため、この作業は両方にとって有用です。また、この同じ取り組みから両方のオプションが出てくる可能性もあります。いずれにせよ、これはまだ解決すべき多くの問題を抱えた実験に過ぎず、結果を待つ必要があります。プロジェクト目標は@camelidによって提案され、推進されています。

cargo checkとcargo buildのキャッシュ共有 🔗

@blyxyasは、cargoがcargo checkとcargo build間で成果物を共有できるようにするプロジェクト目標に取り組んでいます。目標は実際にはより一般的ですが、これが最も認識されやすい成果でしょう。これは長年望まれていたことなので、この分野での進展を見るのは非常にクールです。

これはすでに発表されており、ワークロードに応じてターゲットディレクトリのサイズを5〜30%削減します。

新しいcargoビルドディレクトリレイアウト 🔗

すでに発表されているこのプロジェクトも、かなりの時間開発が進められてきました。上記の他のものと同様に、これは他のことを可能にする主要な内部再構築です。具体的には、ターゲットディレクトリの粒度のロックと、ワークスペースをまたいだキャッシュです。

no-link/link-only 🔗

@bjorn3は、ビルドスクリプトとプロックマクロのパイプライン処理を可能にするこれらの2つのフラグのサポートを修正に取り組んでいます。提案で見られるように、これもまた、突然大きなことがアンロックされるまで、内部的な問題やアーキテクチャ上の問題のリストを修正することに帰着する作業ラインです。

アーキテクチャ 🔗

コンパイラアーキテクチャには多くのイニシアチブがありました。いくつか言及するだけで、（再び）大きなことは突然現れる大きなプロジェクトから生まれるのではなく、健全なシステムへの持続的な長期投資の結果として起こることを強調します。

2年前、@jdonszelmannは、コンパイラでの属性の表現とチェック方法を統一およびクリーンアップする取り組みを開始しました。わずか数日前、最後の属性が新しいシステムにポートされました。これにより、属性のチェック方法が大幅に改善され、診断などの改善が可能になります。

今年初め、@Zalatharと@nnethercoteは、rustcのクエリシステムのインプリメンテーションをクリーンアップしました。これによりパフォーマンスが向上しましたが、より重要なことに、システムが理解しやすくなり、改善のブロッカーとなることがよくありました。システムは依然としてコードベースのかなり恐ろしい部分ですが、これは大きな一歩です。

この分野には実際にもっと多くのアーキテクチャ作業があります。@oli-obkは展開時評価のためのアーキテクチャ的基盤に取り組んでおり、@cjdcilot、@petrochenkov、および私が忘れている他の人々（すみません）によるクエリとインクリメンタル全般に関する多くの作業がありました。同様に、const genericsをさらに進めるために多くの作業が行われました。これらの取り組みの共通のテーマは、コンパイラが以前は制限されていたより多くのコンテキストでその能力を使用できるようになることです。これは、しばしば特定のコンパイルフェーズの厳密な順序のために制限されていました。

プロジェクト目標と資金調達 🔗

メタ的なこともかなりあります。Rustプロジェクトは「プロジェクト目標」と呼ばれる新しい組織フレームワークを実験してきました。

それは様々な変更や実験を経て複数のイテレーションを経ましたが、システムはついに最適な定常状態に達したようで、その利点が表れています。上記のリストから明確にわかると思います。

現在、Fast Buildsロードマップと複数のパフォーマンス関連のプロジェクト目標があります。これは非常にエキサイティングです。

資金調達にも複数の新しい開発があります。1つはプロジェクト目標に明示的に紐付けられており、新しい「Maintainers in Residence」プログラムもあり、新しい資金調達チームも設立されました。

過去1年間、Hexcatが多くの人々を雇用したことから多くの成果が出ていることにも気づかないわけにはいきません。

…そして私 🔗

そして最後に、2026年は私にとってもエキサイティングな年です。数年間傍観者として見ていた後、最終的にパフォーマンスのトリアージに参加するようになり、Rustプロジェクトにより真剣に取り組むことを決意しました。

今年初め、次に何に取り組むべきかを決めなければならないことが明らかになりました。現在の仕事はゆっくりと終わりに近づき、メンテナンスになりつつあり、Webベースの仕事には少し燃え尽き感も感じ始めていました。かなり長い間、より技術的で挑戦的なものに戻りたいという願望を感じていました。

いくつかの選択肢を検討していましたが、どれか一つに決めることができませんでした。マリー・コンドーの言葉を借りれば、何も「喜びの火花」を感じませんでした。いくつかの疲れ果てるような出来事の後、ある晩、それらのすべてから少し落ち込んでいたときに、Rust All Handsへの招待を受けました。これは嬉しい驚きでした。その年の初めに登録していましたが、招待される可能性を知らなかったので、あまり期待していませんでした。これを宇宙からのサインのようなものと捉え、旅行を予約しました。

その経験は圧倒的に肯定的でした。私が長い間参加した中で最もエキサイティングなイベントの1つだったと言わざるを得ません。それは、私の人生の大きな部分が、ほとんど誰とも共有できない、特に現実世界では共有できないことを思い出させてくれました。それを再び体験するまで、それを忘れるのはとても簡単です。

はい、確かに、友人とRustコンパイラの興味深い側面について話すことはできますが、実際にそれに取り組んでいて、あなたが話していることを深く理解している人々と話すのは全く別のレベルです。彼らの仕事で知っている人々に会い、言語開発についての議論に参加できたのは本当に良かったです。

長くなりましたが、これが私のやりたいことだと明確になりました。以前から考えていましたが、おそらく強い「喜びの火花」の瞬間が必要で、自分の感情への疑いを止め、決断を迫られたのでしょう。

Rustで仕事を見つけるには？ 🔗

さて、もちろん、実際にそれをどうやるかという問題があります。ご存知かもしれませんが（そして上で少し示唆したように）、プロジェクトでの仕事を見つけるのは簡単ではありません。「Rust inc.」のような会社に履歴書を送る場所はありません。誰もが何とか自分の道を見つける、断片的で多様な可能性の空間があります。

これらの新しいプログラムによって、よりアクセスしやすくなっていますが、まだ時間がかかるだろうと予想しています。一部はコネクションと信頼に依存しており、これらは時間をかけて構築されます。急ぐ必要はないので、何かを見つけるまで働き続けます。

十分な資金があれば、ターゲットディレクトリサイズ削減プロジェクト目標に取り組むことに同意しました。MiRプログラムにも応募しましたが、資金が限られており、この特定の資金を必要とするより重要な分野があるため、すぐに利用可能になるとは思っていません。

ちなみに、GitHubスポンサーも開設しましたので、コンパイラパフォーマンスの作業をサポートしたい場合は、ぜひ参加してください ;)

結論 🔗

プロジェクトでは非常に多くのことが起こっており、それを十分に伝えるのは本当に難しいと感じています。すでに多くの興味深い作業を省略してしまったように感じていますが、どこかで止めなければなりません。この不完全な概要でさえ興味深いものであったことを願っています。

すべてが肯定的だったわけではないことも言っておくべきだと思います。年の初めは、多くの人々が資金を失い、AIポリシーを巡る激しい議論に影を落とされました。All Handsのわずか数日前に、誰かがポリシーのドラフトをソーシャルメディアに投稿し、私たちの小さなモデレーションチームや他の人々が被害を抑えるためにストレスの多い週末を過ごしました。

これに鑑みると、All Handsは皆がリチャージし、再集中し、ポジティブなエネルギーをプロジェクトに戻すことができる転換点だったと感じています。私は確かにそう感じており、私だけではないことを願っています。