"やさしさとは、ときに拒絶の形をとる。"
Rustで最も特徴的なのは、そのコンパイラが驚くほど厳しいことだ。
それは時に、苛立ちの種になる。
"なぜこれが動かない？ 他の言語なら動いたのに。"
そんな声は、Rustの入門者から必ず聞こえてくる。
だが、その拒絶は、ただの仕様の厳格さではない。
設計を信頼に変えるための、構文レベルでの倫理的防御なのだ。
許されない理由がある：拒絶するコンパイラの哲学
Rustコンパイラは、以下のようなコードを容赦なく拒絶する：
- 未使用の変数
- 所有権が曖昧な値の再利用
- ライフタイムの不整合
- 可変と不変の借用の競合
- 条件分岐における未初期化アクセス
これらは、CやC++なら“とりあえず動く”ことが多い。
だがRustは、「動く」より先に「壊れない」を選ぶ。
“未定義動作”を存在させない構造的前提
C言語におけるバグの多くは、**未定義動作（undefined behavior）**に起因している。
ポインタの解放後アクセス、バッファオーバーラン、二重解放……。
Rustでは、このような**「動くかもしれないが、保証できない」コードを最初から書けない**。
fn main() {
let r;
{
let x = 5;
r = &x; // ライフタイムが切れる → 拒絶される
}
println!("{}", r);
}
このようなコードがコンパイルされないという事実が、
Rustの設計思想＝“静的に正しくなければ、そもそも書かせない” を物語っている。
テストで拾うのではなく、構文で遮る
ほとんどの言語は「動作してみて問題がなければOK」というアプローチを取る。
つまり、安全性はテストやレビューに委ねられている。
Rustではそれが設計構造そのものに埋め込まれている。
動かして問題を見つけるのではない。「書けない」という段階で、問題を消す。
この思想が生み出すのは、開発者の主観を超えた信頼性である。
エラーは設計者への問いである
Rustコンパイラのエラーメッセージは、時に詩的ですらある。
error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
これは単なるコンパイルエラーではない。
「この構造は、本当に安全か？」という設計への問いかけである。
コンパイルエラーとは、言語と設計者との対話であり、
その対話に向き合ったとき、初めて“Rustが許さない理由”が見えてくる。
拒絶によって育まれる「設計の筋力」
初期のRustは、エラーを返すたびに開発者の反感を買った。
だが、開発者は学び、次第にこう感じるようになる。
- 「この設計は破綻している」と、コードを書く前に気づけるようになる
- コンパイラが通るということが、ある種の“設計レビュー”を通過した感覚になる
この“拒絶される経験”こそが、設計を成長させる環境としてRustを機能させている。
許されないコードは、構造として間違っている
Rustにおいて「書けないコード」は、「動かしてはいけない設計」である。
それは自由の否定ではなく、未来のバグの予防であり、責任の制限である。
- 明示されていない所有権は許されない
- 意図されない共有も許されない
- 不確定な時間軸のアクセスも許されない
それらは、すべて“設計者の信頼”を裏切る可能性を孕んでいる。
だからこそ、Rustはそれを構文で拒絶する。
結語：設計を育てる拒絶の構文
多くの言語は、開発者に「動く自由」を与える。
Rustは、開発者に「壊さない制約」を課す。
この構文的な厳格さは、単なるエラーの多さではない。
**設計を透明にし、意図を保証し、信頼を構造で伝えるための“拒絶としての優しさ”**である。
"書けないことで、救われる設計がある。Rustはその静かな守護者なのだ。"