30
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

GoogleがProtobufとgRPCのRust公式サポート発表 - 広がる賛否両論

Last updated at Posted at 2025-06-03

RustエコシステムでProtobufとgRPCを使用する開発者にとって重要な転機が訪れています。GoogleがRustでのProtobufとgRPCの公式サポートを発表したものの、その実装方針がコミュニティに波紋を広げています。

何が起こっているのか

GoogleによるRust向けProtobuf公式サポートが進行しています。最も象徴的な変化は、これまでstepancheg氏が個人で開発していたprotobufクレートの所有権がGoogleに移譲されたことです。crates.ioを確認すると、バージョン3.x系までは従来の開発者によるものですが、4.x系のプレリリース版からはGoogleが直接メンテナンスを担当していることがわかります。

この公式サポートには大きな方針転換が伴っています。新しいバージョン4.x系では、純粋なRust実装から、CまたはC++のバインディングベースの実装に変更されているのです。Google公式の説明によれば、「高品質なRust APIを提供し、純粋なC実装(upb)またはProtobuf C++実装によってバックアップされる」アプローチを採用するとしています。

この変更について、Rustコミュニティでは賛否両論の声が上がっています。

開発者が抱く懸念

RustとC/C++コードを組み合わせることの難しさを経験した開発者からは、具体的な問題点が指摘されています。まず、ビルド環境の複雑化が避けられません。純粋なRustの依存関係であればcargo build一つで済むところが、C/C++コンパイラの適切なバージョンや外部依存関係のインストールが必要になります。特に継続的インテグレーション環境では、これらの依存関係がビルド失敗の原因になりがちです。

WebAssembly環境での制約も重要な問題です。WASM32ターゲットではC FFIが利用できないため、WebAssembly向けのアプリケーションでは新しいGoogle公式実装を使用できません。また、クロスコンパイルが困難になる傾向があり、Rustの「一度書けばどこでも動く」という利点が損なわれる可能性があります。

過去の他言語での事例から、Googleへの不信感もあります。特にPythonでのgrpcioについて、長年にわたるデッドロック問題や、システムの証明書ストアやDNSリゾルバをバイパスする動作、特定のTLS暗号スイートの強制など、多くの問題が報告されています。事前コンパイルステップがあるにも関わらず実行時リフレクションに依存する重い実装や、頻繁な破壊的変更も、開発者の懸念材料となっています。

内部からの視点

この議論にTonicライブラリのメンテナであるlucio-rs氏が参加し、内部の状況について説明しています。同氏によると、Googleは既存のRustエコシステムを破綻させることなく実装を進めたいと考えており、1年以上にわたって協力関係を築いているとのことです。

計画では、既存のprost + tonic利用者を放棄することはなく、新しいgrpc-rust/tonicでもprostを第一級の統合として継続サポートする予定です。ただし、prostを使用する場合は完全な機能セットを利用できない可能性もあります。また、TonicはCNCFにアップストリームされ、gRPCのGitHub組織に移管される予定とのことです。

これらの説明は、Googleが単純にコミュニティを無視しているわけではないことを示していますが、同時に大きな変化も避けられないことが明らかです。

現実的な選択肢

現在、Rust開発者には複数の選択肢があります。従来からのprostライブラリはシンプルで効果的なソリューションとして多くの開発者に支持されています。tonicと組み合わせることで、純粋なRustでのgRPC開発が可能です。

一方、新しいGoogle公式のprotobufクレートは、Googleの内部ニーズ、特に複数言語混在バイナリでのゼロコスト変換やコードサイズの最小化に最適化されています。大企業で既にC++のProtobufを使用している環境では、バインディングベースのアプローチにメリットがあるかもしれません。しかし、Rustファーストのオープンソースプロジェクトにとっては、設計に賛同できない状況です。

多くの開発者は、当面prostの継続使用を表明しています。WebAssembly環境での使用を考慮している場合や、ビルドプロセスの複雑化を避けたい場合、純粋なRust実装の利点を重視する場合には、prostが現実的な選択肢となります。

Rustエコシステムへの影響

今回の一件はRustエコシステム全体にとって重要な意味を持っています。Googleのような大企業が公式サポートを提供することは、一般的には歓迎すべき出来事です。しかし、その実装方針がコミュニティの期待や価値観と必ずしも一致しないという現実も浮き彫りになりました。

Rustコミュニティが大切にしてきた「安全性」「簡潔性」「相互運用性」という価値観と、企業の実用的なニーズとの間にはギャップがあります。このギャップをどのように埋めていくかが、今後のRustエコシステムの発展にとって重要な課題となります。

また、オープンソースプロジェクトにおける意思決定プロセスの難しさも露呈しています。個人開発者から大企業への移管は、リソースの面では有利ですが、開発方針や優先順位の変更を伴う可能性があります。

これからの展望

今後数ヶ月間で、より詳細な情報や移行計画が公開される予定です。

もし既存のプロジェクトを運用している場合は、以下の点を考慮することをお勧めします。まず、現在使用しているライブラリの継続サポート期間を確認し、必要に応じて移行計画を策定することです。WebAssembly環境やクロスコンパイルが必要な場合は、技術的制約への注目が必要です。

GoogleのRust公式サポートは確実に進歩していますが、その道のりは必ずしも平坦ではなさそうです。コミュニティと企業の協力により、最終的にはRustエコシステム全体の発展につながることが理想ですが、そのようになるでしょうか。

参考リンク

30
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
30
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?