Rust は、C/C++ と同等の実行速度と低水準の制御を保ちながら、メモリ安全性とデータ競合の不在をコンパイル時に保証するシステムプログラミング言語。ガベージコレクタを持たない。
| 項目 | 内容 |
|---|---|
| 起源 | Mozilla の研究プロジェクトとして始まり、2015 年に 1.0。現在は Rust Foundation と Rust Project(各チーム)が運営 |
| 実行形態 | LLVM バックエンドでネイティブコードへ AOT コンパイル。ランタイムはほぼ無い |
| ライセンス | MIT / Apache-2.0 のデュアル |
| 公式サイト | rust-lang.org |
値には所有者がちょうど 1 つあり、所有者がスコープを抜けると値は解放される(RAII)。代入・関数への受け渡しは既定でムーブになり、元の変数は使えなくなる。
参照は「共有参照 &T を何個でも」か「可変参照 &mut T を 1 個だけ」のどちらか。この規則を借用チェッカが検査し、ダングリングポインタ・二重解放・データ競合をコンパイル時に排除する。
fn main() {
let s = String::from("hello");
let r = &s; // 共有参照
println!("{r}");
let t = s; // ムーブ。以降 s は使えない
println!("{t}");
}
参照が有効な期間を型の一部('a)として扱う。多くは推論され、関数シグネチャで曖昧なときだけ明示する。
生ポインタ操作・FFI など、コンパイラが検証できない操作は unsafe ブロックに閉じ込める。安全な API で包んで外に出すのが基本の作法。
dyn Traitenum と match による網羅的なパターンマッチOption<T>、失敗は Result<T, E>。? 演算子で伝播する。回復不能な失敗は panic!async/await は言語機能だが、実行器(ランタイム)は標準に無く、Tokio 等のクレートを選ぶmacro_rules!)と手続き的マクロ(derive 等)| ツール | 役割 |
|---|---|
rustup | ツールチェーン(stable / beta / nightly)とターゲットの管理 |
cargo | ビルド・依存管理・テスト・ベンチ・公開を一括で担う。設定は Cargo.toml |
| crates.io | 公式のパッケージレジストリ |
rustfmt / clippy | 整形 / リンタ |
| rust-analyzer | LSP サーバ。VS Code 等で補完・型表示 |
rustdoc | ドキュメント生成。doc コメント中のコード例はテストとして実行される |
手元の環境(2026-10-20 に実測)。rustup(winget の Rustlang.Rustup)で入れ、stable を既定にしている:
rustc 1.99.1 (58cf8f9c3 2026-10-13)
cargo 1.99.1 (5f94df478 2026-08-27)
rustup 1.29.1 (d95a37b6a 2026-08-13)
rustup update が使えない。更新し続けるなら rustup で入れる。stable は 6 週間ごとに出る。後方互換を保つため、stable のコードは新しいコンパイラでもそのまま通るのが原則。
| 版 | 公開日 | 主な内容 |
|---|---|---|
| 1.93.0 | 2026-01-22 | — |
| 1.94.0 | 2026-03-05 | スライスの array_windows()・element_offset()、Peekable::next_if_map() 等 |
| 1.96.0 | 2026-05-28 | Cargo の脆弱性(中・低)の修正を含む |
| 1.96.1 | 2026-06-30 | MIR 最適化の誤コンパイル修正、Cargo の HTTP タイムアウト修正、libssh2 の脆弱性対応 |
| 1.99.1 | 2026-10-13 | 2026-10-20 時点の stable(rustup update で実測)。内容は未調査 |
最新版は rustup update と 公式のリリース一覧 で確かめる。
互換性を壊す変更は Edition(2015 / 2018 / 2021 / 2024)単位で入れ、クレートごとに Cargo.toml の edition で選ぶ。異なる Edition のクレート同士も混ぜてリンクできる。2024 Edition は Rust 1.85(2025-02-20)で安定化。次の Edition(2027 案)は議論段階で、公式な決定は確認できなかった。
no_std でマイコン向けにも書ける米国の政府機関などがメモリ安全な言語への移行を推奨しており、C/C++ の置き換え先として名前が挙がることが多い。
| 観点 | 長所 | 短所 |
|---|---|---|
| 安全性 | メモリ・スレッド安全をコンパイル時に保証 | 借用チェッカに通る設計へ慣れるまで時間がかかる |
| 性能 | GC 停止が無く、C/C++ 並み | — |
| ビルド | cargo で依存管理が統一 | コンパイルが遅い。依存が増えるとビルド時間と成果物が膨らむ |
| エコシステム | crates.io が充実 | 非同期ランタイムが分かれる。GUI は定番が定まっていない |
| 配布 | 単一の実行ファイル | Windows の MSVC ターゲットは Visual Studio Build Tools が要る |
性能と安全性の両方が要る部品・長く保守する常駐プログラム・配布する CLI には向く。試作を速く回したい用途や、GC 言語で十分な業務アプリでは学習コストが上回りやすい。