ADR-0002: Rust as the Implementation Language
Status: Accepted
Date: 2026-06-27
Deciders: Architecture Team
Supersedes: —
Context
Section titled “Context”The platform runs long-lived, concurrent, security-sensitive services (runtime, workflow engine, sandboxed tool execution) where performance, memory safety, and predictable resource use matter. We must pick a primary implementation language.
Decision
Section titled “Decision”Use Rust for all backend services and SDKs (“Rust First”, per the Vision). The dashboard frontend uses Angular/NestSJS (a deliberate exception for the web tier).
Rationale:
- Memory safety without GC → no GC pauses, predictable latency for hot paths (gateway overhead, retrieval, scheduling).
- Fearless concurrency → safe high-concurrency services.
- Performance → meets aggressive NFR targets.
- Strong type system → encodes invariants (DSL, state machine) at compile time.
- Single static binaries → simple, small container images.
Consequences
Section titled “Consequences”Positive
- High performance and safety; small, dependency-free deployables.
- Compile-time guarantees reduce whole classes of runtime bugs.
- Excellent for sandboxing/WASM host integration (Tool Runtime).
Negative
- Steeper learning curve; smaller hiring pool than mainstream GC languages.
- Longer compile times (mitigated by workspace caching,
nextest). - Some AI/ML ecosystem libraries are younger than Python equivalents — mitigated by the Provider SDK abstraction over HTTP provider APIs rather than in-process ML.
Alternatives Considered
Section titled “Alternatives Considered”- Go — simpler, good concurrency, but GC pauses and weaker type guarantees for the DSL/state invariants. Rejected for latency-critical core.
- Python — rich AI ecosystem but unsuitable for high-throughput, low-latency, safe concurrent services. Used (if at all) only at the edges, not the core.
- JVM (Kotlin/Java) — capable but heavier runtime/footprint and GC. Rejected.