ADR-0007: 実装言語は Rust とし、コアは標準ライブラリのみで書く
状態: Accepted
文脈
99-open-questions.md Q3。候補は Rust / Zig / C++ / Go。
制約は以下である。
- 常駐しない(ADR-0002)ため起動時間が毎回課金される。目標 10ms 以下
- mmap、
flock、並列評価、キャンセルを扱う
- 単一バイナリで配布したい
決定
実装言語を Rust とする。ワークスペースのコアクレートは Rust 標準ライブラリのみに依存し、
外部 crate の追加は都度の合意を要する。
根拠
Rust を採る理由
- GC を持たないため、キャンセル応答性が実行環境の都合で劣化しない。
Go の懸念(Q3 に記載)はここに掛かる
- mmap /
flock は libc 相当の FFI を要するが、単一 crate(あるいは薄い自前 FFI)で足りる
- 参照する先行例が Rust 実装である。Salsa と rust-analyzer は、
20-architecture.md 1〜3節が丸ごと写している構造の実物である
- 単一バイナリの静的配布が既定の挙動である
採らなかった案
- Zig — 単一バイナリとツールチェーン同梱の点で適合するが、
言語自体が非安定であり、本システムの寿命(長期保守)と噛み合わない
- C++ — 自己ホスティング的な説得力はあるが、増分エンジンとキャンセルの
実装コストが最も高い。差別化点の実装に割ける労力が減る
- Go — 起動と実装容易性で優るが、GC がキャンセル応答性に与える影響の検証が
前提となり、その検証コストが Rust を選ぶコストを上回らない
標準ライブラリのみとする理由
外部 crate を素朴に採ると、次の3つが同時に損なわれる。
- 起動時間 — 動的リンクと初期化コードが増える。10ms 予算は
clap + serde + tracing 程度の構成でも実測で圧迫される
- 依存の統制 — サプライチェーン施策(cooldown、ライセンス許可リスト)を
設計に含める以上、自身の依存木を統制できない状態は一貫しない
- 設計の外注 — CST 表現(
rowan)とクエリエンジン(salsa)は
本システムの中心的な設計事項である。既製品に合わせると
20-architecture.md 2節の4制約を他者の都合で決めることになる
したがって CST、増分エンジン、診断、ログ、JSON 出力は自前とする。
帰結
- CST・パーサ・診断・ログ・JSON 直列化を自前で持つ。初期コストを受け入れる
- mmap /
flock を要する段階(永続化ストア)で、libc への依存または
自前の extern "C" 宣言のどちらを採るかを別途決める
cargo をビルドに用いる。これは本システムが自己ホスティングするまでの暫定である
- 整形は
cargo fmt、静的解析は cargo clippy。
50-development.md 5節に追記する
- 外部 crate の追加はこの ADR を参照して個別に合意する。
合意した場合は本 ADR に追記するのではなく、追加分を記録する ADR を起こす