なぜRustはすべてを“変更不可”から始めるのか？

Rustでは、変数はデフォルトで不変である。

let x = 5;
x = 6; // エラー: 不変な変数に再代入はできない

変更を許すには、明示的に mut を指定する必要がある。

let mut x = 5;
x = 6; // OK

これは、「変更してよい」と設計者が明言した変数だけが変わることを許されるという、
“意図の明示”による責任設計なのである。

不変性とは「できること」を減らすのではなく、「考慮を減らす」ことである

変数が変わらないということは、それについて考慮すべき分岐が減るということだ。

不変性は、これらの懸念をすべて構造の外に追いやる。
つまり、考えるべきことが減る＝設計の透明性が増すのである。

関数の引数も不変が基本であり、書き換えを意図するならば参照とmutabilityを組み合わせて書く必要がある。

fn update(val: &mut i32) {
    *val += 1;
}

このような構文は、意図的に「ここで状態が変わる」と宣言することでのみ、変更を許す。

これは副作用を「許容」するのではなく、「構造に組み込む」ことに他ならない。

Rustでは、イミュータブルな値は複数のスレッドから同時に借用可能である。
なぜなら、変化しないものは競合しないからだ。

let data = Arc::new(String::from("Hello"));
let d1 = data.clone();
let d2 = data.clone(); // OK: 不変なら何者とも争わない

この設計が示すのは、不変性がスレッドセーフを“保証するための構造”であるということだ。

不変性がもたらすのは次の3つである：

この“安心”こそが、設計における信頼性の土台なのだ。

Rustは変化を禁じているわけではない。
むしろ、意図が明確にされた“必要な変化”だけを構文で許している。

これは言語仕様というより、変化に対する倫理的態度である。

こうした問いを書くたびに開発者に突きつける。
だからRustのコードは、設計者の“誠実さ”がにじみ出る。

変わるものに人は慎重になる。
変わらないものは、それだけで構造的な信頼を得る。

Rustのイミュータビリティは、
単なる最適化やスレッドセーフのための手段ではない。
それは「設計が信頼に値する状態であるか」を問い続ける仕組みである。

"自由に変えることは自由ではない。変えないことを選べる構造こそが、設計の自由である。"