- Gitプロジェクトは今後、Rustをコアに導入し、Git 3.0からはRustがビルドの必須要件になると正式発表
- 今回のパッチシリーズは、過去のC99機能導入と同様に**試験的導入(test balloon)**の性格で進められ、Rust導入インフラを段階的に整備することが目的
- 第一段階として、依存関係がほとんどないvarint.cモジュールをRustに変換し、C-Rust相互運用性とビルドツール群を検証
- 現時点ではMesonビルドのみをサポートし、今後はMakefileサポートとCIでのRustビルド検証および
cargo formatベースのフォーマット一貫性チェックを追加予定
- これはGitコミュニティとディストリビューターに、新たなRustツールチェイン要件に適応する時間を与えつつ、長期的にコードの安全性と拡張性を高める重要な変化
Rust導入の背景
- Gitは安定性と保守性のために、言語面での進化を検討してきた
- Rust導入には、メモリ安全性の強化、モダンなツールチェインの活用、性能最適化の可能性を確保する意味がある
- あわせて、モダンな言語の導入を通じて、より堅牢なコードベースを構築しようとしている
- Git 3.0リリース時点でRustが必須になることを事前に告知し、エコシステムの準備時間を確保する目的
- 段階的にRustコードの適用範囲を拡大し、最終的には一部の中核機能もRustで再実装する方針
試験的パッチシリーズ
- Rustの最初の適用モジュールとしてvarint.cを選定
- 非常に単純で依存関係がない
- C ↔ Rust interop検証が可能
- Git全体の機能に影響を与えずに実験できる
- すべてのテストはvarint.rs版で通過
ビルドシステムの変化
- 現在はMesonビルドシステムでのみRustサポートを追加
- 今後MakefileにもRustサポートを追加する計画
- CI関連の作業も準備が必要
- Rustビルドおよび動作検証
cargo formatによるコードスタイルの一貫性確保- その他のツール整備および保守自動化
今後の計画
- 今回の作業はRust機能そのものよりも、導入プロセスの実験に重点がある
- 今後はxdiffモジュールを含め、さらに多くのGit内部機能をRustで書き直す可能性がある
- Rustを段階的に拡張適用しながら、エコシステム全体がRustベースのビルド環境に適応するよう促す予定
示唆
- Gitは歴史上もっとも重要な言語的転換を準備している
- Rust必須化により、安全性・保守性・長期的な発展可能性を確保できる
- ディストリビューターおよび開発者にとって、今後のGitエコシステムではRust開発環境の構築が必須になる
1件のコメント
Hacker Newsの意見
関連議論へのリンク
Rustサポートも標準のない言語である以上、時間がたつと実装が大きく遅れることになりそうだと疑っている（過去のJavaのように）
Gitはすでに完成度の高いツールに見え、必要なのは保守や改善程度であり、新しい言語を導入するほど大規模な新規コードが必要には見えない
Linuxのように新しいドライバが継続的に必要な場合と違って、Gitにはそのような理由が見当たらない
自分が何か見落としているのなら説明してほしいとしている
Gitの変更点はRelNotesで確認でき、あるいは GitHubブログのGitカテゴリ でより見やすく確認できる
git-branchlessにはRustで書かれたインメモリマージなどの機能がある
Rust関連の話はそのメーリングリストでさらに探せばよい
（賛否を自分で評価するつもりはなく、誰かがやってくれるだろうという話）
CでGitを開発したい人はほとんどいない一方、Rustでの書き換えに関心を持つ開発者は参加に意欲的だ
Gitは完成度が高く、新しいコードもそれほど多く追加されないように思える
RustはCに比べてはるかに複雑だ
本当にオブジェクト指向機能が必要なら、C++98程度だけでも最近のC++やRustよりずっと単純で理解しやすい
Rustが今後のパッチに必須になるのではなく、ビルドシステム内で必須になる予定だということ
もし違っていれば再修正できるとも言っている
ビルドシステム自体をビルドするのに必要なのか、それともアプリケーションのビルドにも必須なのかが気になるという話
Gitに深く投資し、さまざまなプロジェクトも作ってきたので、Gitのハックしやすさを失いたくないという思いがある
実際にはRustは一般的なC（特にバグの多いC）より学びやすく、GitやLinuxのソースコードを理解するよりは確実に簡単だ
GitHubベースではC 50%、Shell 38%、Perl 4%、残りがTCL/Pythonなどだ
むしろPerl/TCLのほうが例外的だ
プロジェクトの成長とともにあちこちへ継ぎ足したハック的コードが多くなっており、今は安全性や性能の改善、古いハックの整理が必要な時期だ
Rustはそれに適していると思う
Gitが一部でRustを使うことになっても、自分が作るGitクライアントやサーバの開発が妨げられることはないと思う
Debianリリースノートでも Rust/Goパッケージ関連の問題 が明記されている
Rustパッケージは静的リンクの問題のため頻繁に再ビルドが必要になり、実運用では不便が生じる
Linux OSで必須となる安定ABIや共有ライブラリの問題をRust側が軽視するなら、むしろC以上に多くの不満を生む可能性がある
大規模ソフトウェアアーキテクチャではもっと慎重であるべきだと思う
NonStopというキーワードを この記事 で検索すると事例が分かる
RESFなどでは「プラットフォームがRustをサポートしていない」と表現するが、実際に動くにはRustコンパイラ側のサポートが必要だ
gitは2.xで安定した印象があり、互換性を壊す理由が見当たらない
最近の開発文化はこうしたツールチェーンの使い方から遠ざかっているのではないか、という疑問がある
ソース管理、ビルド、実行環境がそれぞれ異なるため、リモートコピーやリモート実行が必要で、ビルドルールにもターゲットプラットフォームの検出が必須だった
--targetフラグ1つで約100のプラットフォーム向けに大きな問題なくビルドできる実際の問題は、一部のGit開発者がそれぞれ古い／固定された開発マシンの制約にこだわっていることだと見ている
クロスコンパイルは常に二級市民扱いで、外部プロジェクトではまともに動くこと自体あまり期待していない
Linuxディストリビューションでも、Raspberry Piなどは実機上でしかビルドしない場合がある
そのため、これをきちんと支援しようとする努力がほとんど行われない
Linuxが特に深刻で、glibcの構造が古くなっているため、どのハードウェアでも最小限のglibcをターゲットにすることが難しくなっている
ほとんどのプロジェクトは、クロスコンパイル対応そのものを試みてもいない
Zigはこれを改善しようと努力している
Gitはプロジェクトの中核ツールなので、変更のリスクが大きく、6か月のような短期間で必須依存にするのは危険だと見ている
この複雑さはコンパイル時により多くのエラーを捕捉するためのものだが、その結果として言語自体がかなり複雑になっている
こうした点から導入は勧めないという意見
カーネルも同様にRust導入を拒否したと認識している
すでに複雑なカーネルにHaskell級の型システムやLisp級のマクロシステムまで加えれば、複雑さが増す
serde経由のRustコード追跡は難しい
それに比べるとGoのUnmarshalははるかに追いやすい
コンパイラにより多くの情報を持たせられるからだ
Serdeで大きな問題に遭ったことはなく、むしろGoのUnmarshalのデバッグのほうを多くやってきた
カーネルがRustを拒否したという主張も、実際には2人の開発者の間でヘッダの保存場所をめぐって衝突があったという話にすぎない
Rustは参入障壁こそCより高いが、「最低限のRust」と「高速で安全なRust」の間の隔たりは、Cに比べればずっと小さい
borrow checkerと同じくらい重要だと見ている
文法も寛容だ
Linuxカーネルは実際にはRustを拒否していない