Rust vs Go — サーバー、CLI、システムプログラミングで何を選ぶかの基準

「性能の良いコンパイル言語を 1 つ学びたいのですが、Rust と Go のどちらがいいですか」は、絶えず出てくる質問です。2 つの言語は見かけのスペックが似ている(静的型付け、コンパイル、単一バイナリ、並行処理の重視)ので、なおさら迷います。結論から言うと、哲学が正反対に近い言語同士なので、用途を決めれば答えはついてきます。 この記事はその判断基準を整理します。各言語そのものは Go 基礎と Rust 基礎で扱いました。

まず同じところから — どちらも「デプロイが楽な速い言語」 #

共通項ははっきりしています。静的な型検査、ネイティブコンパイル、ランタイムのインストールが要らない単一バイナリ、そして Python・Ruby 比で数十倍水準の処理性能。「スクリプト言語で作ったサービスが遅くなって乗り換え先を探している」状況なら、どちらも正解候補です。分かれ道はその先です。

分かれ道 1: メモリ — GC の単純さ vs 所有権の統制力 #

• Go: ガベージコレクタがメモリを管理します。開発者は割り当てと解放を忘れてロジックに集中し、代わりに GC が割り込む瞬間の遅延とランタイムのメモリオーバーヘッドを受け入れます。現代の Go の GC 停止はミリ秒未満の水準まで短く、大半のサービスで問題になりません。
• Rust: 所有権規則でコンパイル時に解放タイミングを確定します。GC がないので停止もなく、メモリ使用量も予測可能ですが、その規則を学ぶコストを前払いします。

「平均は十分速い。問題は最悪の瞬間か」が判別の質問です。 p99 レイテンシやメモリ上限が契約条件になるシステム(トレーディング、リアルタイム処理、メモリ制約環境)なら Rust の統制力が元を取り、そうでない一般的なサービスなら Go の単純さが勝ちます。

分かれ道 2: 並行処理 — 組み込みのゴルーチン vs async エコシステム #

• Go: ゴルーチンとチャネルが言語に組み込まれています。go f() の 1 行で数十万の軽量スレッドを立ち上げ、ランタイムのスケジューラが自動で配分します。並行コードへの参入障壁は主要言語の中で最も低い部類です。
• Rust: async/await は言語の文法ですが、実行環境はエコシステム(tokio が事実上の標準)から持ってきます。組み合わせの自由と細かい制御を得る代わりに、「どのランタイム、どのクレート」という選択が学習曲線に加わります。その代わり、コンパイラがデータ競合を根本から遮断するのは Rust だけの利点です(実践第 5 回で実際の場面を扱いました)。

並行コードを速く、たくさん書くチームなら Go の組み込みモデルが生産性で先行し、並行バグのコストが致命的なドメインなら Rust のコンパイル時保証が先行します。

分かれ道 3: 学習曲線とチーム #

• Go: 言語仕様が小さく文法が単純なので、経験者なら数日から 1〜2 週間で生産的なコードを書けます。「誰が書いても似たコード」になるのが設計目標で、コードレビューとオンボーディングのコストが低いです。
• Rust: 所有権・借用・ライフタイムという前払いコストがあります。チーム全員がこの曲線を越える必要があるので、導入は個人の好みではなくチームの投資判断です。その代わり越えてしまえば、「コンパイルが通ればだいたい動く」というデプロイへの信頼が曲線の対価を返してくれます。

採用市場と組織規模も変数です。急いで人員を増やす必要がある組織では、Go のオンボーディングコストの低さが実質的な利点になります。

用途別のお勧め #

まとめ #

• どちらも「速くてデプロイが楽な言語」という共通項の上にあり、分かれ道はメモリ・並行処理・学習曲線の 3 軸です。
• 判別の質問は「最悪の瞬間(GC 停止、並行バグ、メモリ上限)が契約条件か」です。そうなら Rust の前払いコストが元を取り、違うなら Go の単純さが勝ちます。
• Web API と速いチーム拡大は Go、CLI・組み込み・Python 高速化・性能クリティカルなコアは Rust が基本のお勧めです。
• 学ぶ順番として 1 つ選ぶなら、バックエンド志向は Go から、システム・ツール志向は Rust からが無難です。2 つの言語は競合というより、カバーする領域が違う道具です。