静かなる収束 ── なぜ Go、Rust、Kotlin は同じ方向へ向かうのか、そしてそれが意味すること

うまく言葉にできない感覚

Java や C# と何年も付き合ってきた開発者が、初めて Rust や Kotlin に触れた瞬間に感じる、独特の感覚があります。それは「軽さ」です。

「この言語は学びやすい」という意味の軽さではありません。むしろ、ちょうど片付けが終わった部屋のような軽さです。キーワードで埋め尽くされていないコードの行。二度書かなくてもよい型。かつての public static final ── 消えました。延々と続く getter と setter ── 消えました。あの頑固なセミコロンさえも……消えました。

古い Java で何百回も書いてきたことを、Rust の関数で書いてみた時のことを覚えています。何か忘れているのではないかと思い続けました。こんなに短くて？本当に？ そう、本当に動きました。コンパイラは文句を言いませんでした。

しかし、その「軽さ」は偶然の産物ではありません。流行でもありません。これは、コンピュータサイエンスにおける50年間の思考の変化の結果なのです ── 誰が難しい部分を担うべきか、人間か、それとも機械か、という問いをめぐって。

この記事では、その構文革命を支えてきた四つの柱を、あなたと一緒に深く掘り下げていきたいと思います。そして、それ以上に大切なこと ── これは「美しい」か「醜い」かの話ではなく、21世紀のプログラミング哲学についての物語なのだということを。

少しの歴史 ── なぜ古い構文は「重い」のか

Java、C、C# を批判するのが開発者の反射神経になる前に、公平な問いを立ててみましょう。なぜ、これらの言語はそのように設計されたのか？

答えは、それらが生まれた時代のハードウェアとコンパイラの現実にあります。

C(1972年) は、数十キロバイトの RAM しか持たない PDP-11 マシン上で誕生しました。1バイトたりとも貴重でした。コンパイラは、キーワードからアセンブリへの「翻訳機」と呼べる程度に単純でなければなりませんでした。すべてを明示的に書かなければならなかったのは、コンパイラにあなたの代わりに考える「余裕」がなかったからです。型推論は学術論文の中にしか存在せず、製品レベルには届いていませんでした。

Java(1995年) は、インターネット黎明期に「一度書けば、どこでも動く(Write Once, Run Anywhere)」という問題を解くために生まれました。James Gosling の哲学は、コードを明示的に、読みやすく、安全にすることでした。型宣言を必須とする選択は、意図的なものでした ── 大企業の大規模チームで、多くの人がコードを読み、保守できるようにするために。

C#(2000年) は、Microsoft による Java への応答でした。「明示的であることがよい」という哲学を多く受け継ぎながら、より実用的でした。そして後に、モダンな機能の取り込みにおいて Java よりずっと速く動くようになります。

これらの言語は「間違っている」のではありません。その時代に合っていたのです。今日私たちが「ボイラープレート」と呼ぶものは、25年前には「コードに自然に埋め込まれたドキュメント」だったのです。public static final String CONFIG_KEY を読めば、他のどこも見なくても、その変数についてのすべてを正確に知ることができました。

しかし、時代は変わりました。

コンパイラは千倍賢くなりました。ハードウェアは、数サイクルの CPU を節約することがほとんど意味を持たないほど安くなりました。そして何より重要なのは、現代のソフトウェア企業にとって、開発者の時間こそが最も高価なリソースだということです。

これが、これから語る四つの柱の土台です。

第一の柱:型推論 ── コンパイラが推測できるほど賢くなった時

これは、二つの世代の間で最も目につく違いかもしれません。

問題:無意味なまでの繰り返し

Java 7 以前の典型的な宣言を見てみましょう。

java

Map<String, List<User>> registry = new HashMap<String, List<User>>();

この一文は、同じ情報を三回伝えています。宣言の場所で、コンストラクタで、そして(間接的に)ジェネリック型で。あなた ── 人間 ── は、右辺を書いた瞬間に registry が何の型になるかを既に知っていました。コンパイラも推論できたはずです。では、なぜもう一度言わなければならなかったのでしょうか？

答え:初期のコンパイラがそれほど賢くなかったからです。しかし、今は違います。

数十年にわたる進化

java

// Java 6 (2006) ── ボイラープレートのピーク時代
Map<String, List<User>> registry = new HashMap<String, List<User>>();

// Java 7 (2011) ── ダイヤモンド演算子で苦痛が半減
Map<String, List<User>> registry = new HashMap<>();

// Java 10+ (2018) ── ほぼ10年後、ようやく var が登場
var registry = new HashMap<String, List<User>>();

go

// Go ── := 演算子は「宣言+推論」を一つにまとめたもの
registry := make(map[string][]User)

kotlin

// Kotlin ── val/var が可変性を明確に区別する
val registry = hashMapOf<String, List<User>>()

rust

// Rust ── 型を完全に省略できる
let mut registry = HashMap::new();
registry.insert("alice".to_string(), vec![user1]);
// Rust は下の行を見て、逆向きに推論する:HashMap<String, Vec<User>>

どの行も同じ仕事をしています。違いは、型注釈を誰が書くか ── 開発者か、コンパイラか ── という点だけです。

あまり知られていない技術的な詳細:すべての型推論が同じではない

• Rust は Hindley-Milner 型推論の変種を使っています。これは ML や Haskell に根を持つアルゴリズムで、後方推論が可能です(後の行での使われ方から変数の型を推論する)。

• Go はもっと単純なローカル型推論を使っています。右から左への推論のみで、後方推論はありません。だからこそ、Go の := 演算子は、右辺に十分な情報がある時にしか機能しないのです。

• Kotlin はその中間に位置します。Go より強力ですが、連鎖的な後方推論において Rust ほどの深さには至りません。

推論が賢くなればなるほど短く書けますが、何かが壊れた時のエラーメッセージはそれだけ難しくなります。これは意図的な設計上のトレードオフです。

val 対 var ── 単なる構文の話ではない

多くの初心者が見落とす重要な点:**不変性(イミュータブル)**です。

• Kotlin の val =「一度だけ代入されるバインディング」(Java の final、一部の言語の const に相当)

• Kotlin の var =「再代入可能なバインディング」

• Rust の let はデフォルトで不変。再代入を許可するには let mut と書かなければなりません

これは単なる構文の問題ではありません。モダンな言語は、不変性をデフォルトに押し上げようとしているのです。なぜなら、数十年にわたるソフトウェア開発の経験が、私たちに苦い教訓を教えてくれたからです ── 自由に変わる状態こそが、特にマルチスレッド環境において、最も理解しがたいバグの根源なのだと。

第二の柱:式指向(Expression-Oriented) ── 文章のように読めるコード

この違いは型推論より深く、気づきにくいものですが、コードを書く時の考え方そのものを形作ります。

Statement(文)と Expression(式)の根本的な違い

• Statement(文):「何かをしなさい」とコンピュータに指示するもの。値を返しません。例:Java の if (x > 0) { doSomething(); }

• Expression(式):評価して値を生み出せるもの。例:2 + 3 は 5 を返し、x > 0 は true/false を返します。

C、Java、伝統的な C# は文指向(statement-oriented) です。if、try、for のようなブロックは文であり、値を返しません。値を取り出すには、一時変数を作るか、三項演算子 ? : を使わなければなりません。

Rust、Kotlin(そしてある程度 Scala や F#)は式指向(expression-oriented) です。ほとんどすべてが値を返す式です。

直接比較

シナリオ:健康度に基づいてステータスを割り当てる。

伝統的な Java ── 可変な一時変数が必要:

java

String status;
if (health > 50) {
    status = "Healthy";
} else if (health > 20) {
    status = "Warning";
} else {
    status = "Critical";
}

三項演算子を使うこともできますが、ケースが増えるとすぐに読めなくなります:

java

String status = health > 50 ? "Healthy" 
              : health > 20 ? "Warning" 
              : "Critical";

Kotlin ── when は式:

kotlin

val status = when {
    health > 50 -> "Healthy"
    health > 20 -> "Warning"
    else        -> "Critical"
}

Rust ── match は式であり、ブロックの最後の式(セミコロンなし)が戻り値:

rust

let status = match health {
    h if h > 50 => "Healthy",
    h if h > 20 => "Warning",
    _           => "Critical",
};

Rust の最も美しい点:「セミコロンのない最後の式が戻り値」というルールは、関数本体にも適用されます。return キーワードは不要です:

rust

fn double(x: i32) -> i32 {
    x * 2  // セミコロンなし ── これが戻り値
}

なぜこれが重要なのか

式指向は「短く書ける」だけの話ではありません。考え方そのものを変えるのです。

1. 可変な状態が減る:if が値を返すなら、var status を宣言して代入し直す必要はありません。デフォルトで val/let(不変)を使うことになります。コードはより明瞭で、推論しやすく、マルチスレッドでも安全です。

2. コードが自然に読める:「status はこれらの値のうちの一つ」── 「変数を作って、条件次第で変化させる」ではなく。

3. 間違える機会が減る:if の分岐が欠けていれば、コンパイラが教えてくれます ── 式は必ず値を生まなければならないからです。Java では、ある分岐で代入を忘れても、変数はスコープ内に「存在」しますが、定義されていない値のままです。

これは関数型プログラミング(Haskell、Lisp、ML)から借用された考え方です ── 主流がようやく追いついたのは、それが学術界で何十年も育まれた後のことでした。

第三の柱:デフォルトで安全 ── バグを実行時からコンパイル時へ移す

これは物語の中で最も哲学的な部分です。そして、最も経済的なインパクトの大きい部分でもあります。

null との戦い ── 10億ドルの過ち

2009年、Tony Hoare ── 1965年に null 参照を発明した人物 ── は、それを公に "my billion-dollar mistake"(私の10億ドルの過ち) と呼びました。NullPointerException に関連するバグは、世界のソフトウェア産業全体で数十億ドルの損害を引き起こしたと推定されています。スマホアプリのクラッシュから、深刻なセキュリティ脆弱性まで。

Java、C#、古典的な C++ では、あらゆる参照が null になり得ます。あちこちで防御的なコードを書かなければなりません:

java

if (user != null) {
    Address address = user.getAddress();
    if (address != null) {
        String street = address.getStreet();
        if (street != null) {
            // ...street で何かをする
        }
    }
}

これが「破滅の階段(staircase of doom)」── すべての Java 開発者が嫌というほど知っている、地獄への下り階段です。

新世代の解決策:null を型システムに埋め込む

Kotlin は nullable を型システムに持ち込みました。デフォルトでは、変数は null になれません:

kotlin

val name: String = "Alice"      // 決して null ではない ── コンパイラが保証
val nick: String? = null         // 明示的に nullable ── 必ず処理しなければならない

// nullable を使う時、コンパイラが処理を強制する:
val length = nick?.length ?: 0   // セーフコール + エルビス演算子

Rust はさらに踏み込んでいます ── null という概念がそもそもありません。代わりに Option<T> を使います:

rust

let name: String = String::from("Alice");
let nick: Option<String> = None;

// 値を取り出すには match が必須:
match nick {
    Some(n) => println!("Nick: {}", n),
    None    => println!("ニックネームなし"),
}

null が消えたのではありません ── それは型に符号化され、コンパイラがコンパイル時にあらゆるケースをチェックするよう強制されているのです。もう深夜3時に NullPointerException に悩まされることはありません。

メモリ管理:三つの哲学、三つの道

言語がメモリをどのように片付けるかは、その言語の構文全体を形作ります。三つの道を見ていきましょう。

1. 手動(C、C++)

c

char* buffer = malloc(1024);
// ...buffer を使う...
free(buffer);
// この行を忘れる = メモリリーク
// 二回呼ぶ = 未定義動作
// 解放後に使う = use-after-free → 重大なセキュリティ脆弱性

絶対的な自由、絶対的な責任。歴史上の壊滅的なセキュリティホール(Heartbleed、EternalBlue、無数のブラウザ CVE)のほとんどは、C/C++ のメモリバグに由来します。Microsoft は自社製品のセキュリティ脆弱性の約70%がメモリ安全性の問題だと公に述べています。

2. ガベージコレクタ(Java、C#、Go)

java

String[] buffer = new String[1024];
// ...buffer を使う...
// free 不要 ── 参照がなくなれば GC が片付ける

開発者には簡単です。しかし、GC はバックグラウンドで動くため、予測不能な一時停止を引き起こします ── リアルタイムシステム、ゲームエンジン、低遅延取引にとっては大きな問題です。

Go の GC はサブミリ秒の一時停止に最適化されており、スループットと引き換えにレイテンシを優先しています ── ネットワークサービスに適しています。Java には選べる GC の庭があり(G1、ZGC、Shenandoah)、ZGC は数 TB のヒープでも1ミリ秒未満の一時停止を達成します。

3. 所有権(Rust)── 第三の道

rust

let buffer = String::from("hello");
// ...buffer を使う...
// スコープ終了 → Rust が自動的にデストラクタを呼ぶ ── GC なし、一時停止なし

Rust の哲学:すべての値は、ある瞬間に唯一の「所有者」を持つ。所有者がスコープを抜けると、値は自動的に解放されます ── コンパイル時に既に決定済み。実行時オーバーヘッドはありません。

これは思考の大きな飛躍です。Rust の &、&mut、そして 'a のようなライフタイム注釈は最初は複雑に見えますが、他の言語が無視するか、実行時に処理する情報を符号化しているのです:

rust

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

ここでの 'a は「戻り値は、二つの入力の短いほうと少なくとも同じ長さだけ生存する」と言っています。コンパイラはこの情報を使って、ダングリングポインタが存在しないことを保証します。

高価な構文。しかし、その代わりに:GC なし、実行時オーバーヘッドなし、メモリバグなし ── かつて不可能だと考えられていた組み合わせです。Rust は歴史上初めて、パフォーマンスと安全性のどちらかを選ぶ必要はないことを証明した主流言語なのです。

第四の柱:不要なものを切り捨てる

最後の柱は最も「軽い」ものに見えるかもしれませんが、毎日コードを見ている時に最も目につく部分です。

セミコロン ;

Go、Kotlin、Swift、Python ── すべてが ; を排除するか、オプションにしています。モダンな字句解析器/構文解析器は、その印がなくても文がどこで終わるかを十分賢く判断できます。

面白い詳細:Go は内部ではセミコロンを使っていますが、コンパイラが自動セミコロン挿入(automatic semicolon insertion) で挿入します。あなたは ; なしでコードを書き、コンパイラが追加する ── 結果として、99%の場合あなたはそれについて考える必要がありません。

条件式を囲む括弧 ()

java

// Java
if (x > 0 && y < 10) { /* ... */ }

go

// Go、Rust
if x > 0 && y < 10 { /* ... */ }

小さなことです。しかし、開発者のキャリアで数百万回繰り返される if 文に掛け合わせれば、それは積み重なります。

カプセル化:数千行の getter/setter から最小限へ

古典的な Java はあなたにこう書かせます:

java

public class User {
    private String name;
    private int age;
    
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public int getAge() { return age; }
    public void setAge(int age) { this.age = age; }
    
    @Override public boolean equals(Object o) { /* 10行 */ }
    @Override public int hashCode() { /* 5行 */ }
    @Override public String toString() { /* 3行 */ }
}

これは、たった2フィールドのクラスのための30行以上です。Lombok が救済ライブラリとして登場しましたが、それは絆創膏に過ぎません ── 依存関係、IDE プラグイン、アノテーションプロセッサが必要です。

新しい言語は根本から解決します。

Kotlin の data class:

kotlin

data class User(val name: String, val age: Int)
// equals、hashCode、toString、copy、componentN が自動生成される

Rust の struct と derive マクロ:

rust

#[derive(Debug, Clone, PartialEq)]
struct User {
    name: String,
    age: u32,
}

Go は極端なところまで行きました ── 可視性は頭文字が大文字か小文字かで決まります:

go

type User struct {
    Name string  // public(大文字)
    age  int     // private(小文字)
}

public も private もキーワードなし。デフォルトの getter/setter もなし。極端なまでのミニマリズムが、開発者に規約を考えさせます。

公平を期すために言えば、Java 14以降は record で応答しています:

java

public record User(String name, int age) {}

これは新しい哲学が古い言語に対して勝ち取った勝利です ── そして、これが次のセクションへと私たちを導きます。

反論:「年長者たち」も止まってはいない

これは多くの「モダン言語」礼賛記事が都合よく省略する部分です。Java、C#、C++ は止まってはいません ── 新世代から熱心に学んでいます。

Java はこの5〜7年で、新世界から「借用」した一連の機能を追加してきました:

• var(Java 10、2018年)── ローカル型推論

• switch 式(Java 14、2020年)── Rust 流に switch を式に変換

• テキストブロック(Java 15)── きれいな複数行文字列

• record(Java 16、2021年)── Kotlin スタイルの不変データクラス

• パターンマッチング:instanceof(Java 16)と switch(Java 21)

• シールドクラス(Java 17)── Rust enum のような閉じた階層

• 仮想スレッド(Java 21、2023年)── Go goroutines から借用した並行モデル

C# は実は何年も Java より速く動いてきました ── Microsoft は機能追加においてより実用的でした:

• var(C# 3.0、2007年)── Java よりまる10年早い

• Nullable 参照型(C# 8、2019年)── Kotlin から直接学んだ

• レコード(C# 9、2020年)── Java より先

• 拡張パターンマッチング(C# 11 ではかなり強力)

C++ にも auto、構造化束縛、コンセプト(Haskell/Rust の trait/typeclass のアイデアから借用)、std::optional、スマートポインタ(unique_ptr、shared_ptr)── 一種の「軽量所有権」があります。

では、モダンな Java や C# を使えばよいのでは?

非常にもっともな質問です。答え:レガシーは諸刃の剣だからです。

Java は var を追加しましたが、30年分のレガシーコードと互換性を保たなければなりません。今でも NullPointerException が起こり得ます。今でも GC と共に生きています。今でも同じコードベースに「古い Java」と「新しい Java」が共存し、スタイルの混乱を引き起こし、新人がレガシーコードを読むのを難しくしています。

Rust はゼロからそれらの原則とともに設計されました。レガシーの重荷を背負っていません。これは大きな強みであり ── 同時に大きな障壁でもあります(エコシステムが小さい、ライブラリが少ない、知っている人が少ない、採用が難しい)。

これは「どちらが勝つか」の戦いではありません。これはエコシステムの多様化であり ── 業界全体にとって良いことなのです。

トレードオフ ── 銀の弾丸は存在しない

この記事を新しい言語への賛歌として読まれたくはありません。なぜなら、どんな構文上の選択もトレードオフを伴うからです ── そして、それを認めることが成熟した開発者の証なのです。

強すぎる型推論 → エラーメッセージが理解不能になる。コンパイラが何十ステップも後方推論して矛盾に当たると、Rust や Scala のエラーメッセージは何十行にもわたり、HKT の専門用語で埋め尽くされ、解読に経験が必要です。初心者はしばしば絶望します。

式指向 → 初心者にとってデバッグが難しい。すべてが入れ子になった式の時、伝統的な文指向コードのように print デバッグを挟む自然な「停止点」がありません。

Rust の所有権 → 学習曲線が急峻。借用チェッカ(borrow checker)は有名な壁で、「borrow checker と戦う」数週間を経て Rust を諦める開発者は少なくありません。ラピッドプロトタイピングの生産性は Rust の本当の弱点です。

Go のミニマリスト構文 → プロジェクトが大きくなると、ミニマリズムが繰り返しに変わり得ます(弱いジェネリクスのため、Go 1.18 で初めて追加され、まだ制限があります)。コミュニティの有名な言葉:「Go は小規模プロジェクトには最もミニマルな言語であり、大規模プロジェクトには最も冗長な言語である」。延々と続く if err != nil は永遠のミームです。

Kotlin の null 安全性 → 統合された Java コードからクラッシュし得る(「プラットフォーム型」の概念 ── コンパイラが nullable かどうか知らない型 ── を経由して)。

各言語は、特定の種類の問題のために設計されたトレードオフの集合です:

• Go:ネットワークサービス、マイクロサービス、CLI ツール ── 学習速度と可読性を優先し、表現力を犠牲にする。

• Rust:システムソフトウェア、組み込み、パフォーマンスクリティカル、ブロックチェーン ── 正しさとパフォーマンスを優先し、初期開発速度を犠牲にする。

• Kotlin:Android、JVM バックエンド ── 実用性と Java との相互運用を優先し、理論的「純粋さ」を犠牲にする。

• Java/C#:大規模エンタープライズプロジェクト、大規模チーム、長寿命コードベース ── 安定性、成熟したツーリング、巨大なエコシステムを優先。

• C/C++:カーネル、ドライバ、ゲームエンジン、極めて低レベルなシステム ── 完全な制御を優先。

「最高の言語」は存在しません。あるのは「この問題に最適な言語」だけです。

結論:構文は哲学である、単なるタイピング方法ではない

この記事は長く、ここまで読んでくださったことに感謝します。なぜなら、私が本当に共有したいのは「Rust は Java より優れている」ということではないからです ── それは退屈で、エゴに満ち、問いの立て方を間違えた議論です。

私が言いたいのは:言語の構文上のあらゆる決定は、プログラミングとは何かという、より深い哲学的問いに対する答えなのだということです。

• C があなたに malloc と free を書かせる時、それはこう言っています:「コンピュータは機械であり、整備士が車を理解するように、あなたはそれを理解しなければならない」

• Java が GC を作った時、それはこう言いました:「いや、コンピュータは人間に奉仕すべきだ ── 難しい部分はランタイムに任せよう」

• Rust が所有権を作った時、それはこう言いました:「第三の道がある ── あらゆる難しい決定をコンパイル時に押し付けて、ランタイムは静かに速くいられるようにしよう」

• Kotlin が nullable のために ? を加えた時、それはこう言いました:「10億ドルの過ちがデフォルトであってはならない ── 型システムに符号化しよう」

• Go が13年間ジェネリクスを保留し、ようやく慎重に追加した時、それはこう言いました:「シンプルは簡単ではない ── それは私たちが思うより難しい規律なのだ」

Go、Rust、Kotlin の共有された価値観への静かな収束 ── 型推論、式指向設計、デフォルトの安全性、構文的ミニマリズム ── は偶然ではありません。それは、ほぼ50年の経験を経た業界の成熟です。それは、NullPointerException で過ごした眠れぬ夜、バッファオーバーフローによる無数のハック、getter と setter を書いて費やされた無数の時間の総決算なのです。

今日のプログラマである私たちは、これほど多くの選択肢を持つ時代に生きていることが、驚くほど幸運です。Java の「文指向」から Kotlin/Rust の「式指向」へ、「ランタイムを心配する」から「コンパイル時を心配する」へ、「防御的に書く」から「コンパイラを信じる」へ ── この思考の転換は、本物の旅路です。最初は難しい。次第に慣れる。そして、戻れなくなる。

私は Java や C# を捨てろと言っているのではありません ── それらは依然として偉大なツールであり、毎年改善されており、それらが最も理にかなった選択である問題も存在します。しかし、もしあなたが Rust、Go、Kotlin を 真剣に 試したことがないなら ── 「Hello, World」ではなく、本物のプロジェクトを書くために一ヶ月を費やすという意味で ── 試してみることをお勧めします。「アップグレード」のためでも、流行を追うためでもなく。コードについての考え方を広げるためです。

なぜなら結局、私たちが日々書く言語が、私たちの考え方を形作るからです。Wittgenstein は自然言語についてこう書きました:「私の言語の限界は、私の世界の限界を意味する」。同じことが ── おそらくはもっと強く ── プログラミング言語にも当てはまります。

良い言語を選ぶこと。それは、考えるためのより広い世界を自分に与えることなのです。

💬 あなたの物語は?

ぜひ聞かせてください:

• 日々の仕事でどの言語を使っていますか?そして、なぜですか?

• 古い言語から新しい言語に移った後、「もう戻れない」と気づいた瞬間はありましたか?

• それとも逆に:新しい言語に移った後も、「古い」言語の機能で恋しいものはありますか?

下のコメント欄で共有してください。どの物語も貴重な視点です。

最後まで読んでくださってありがとうございました。この記事が役に立ったなら、次に学ぶ言語に迷っている同僚にぜひシェアしてください。