compare · Rust
fastC vs Rust
The obvious comparison. Rust has more safety machinery and a vastly larger ecosystem; fastC has structural answers Rust cannot retrofit.
Rust is, at the time of writing, the dominant memory-safe systems language outside of GC'd ones. It has a brilliant borrow checker, a mature compiler, and a 150,000-crate ecosystem. The fair version of "why not Rust?" is the one we want to answer here. Some of these rows fastC wins on; some Rust wins on; the point is the honest list.
Row by row
| Dimension | fastC | Rust | Note |
|---|---|---|---|
| Memory safety without GC | Yes — runtime traps + contracts; borrow story weaker than Rust | Yes — borrow checker, the gold standard | Rust wins on hard guarantees here. |
| Capability-typed I/O | Yes — finite named set, minted in main, flows through args | No — ambient std::fs / std::net | fastC's structural wedge. |
| Mandatory contracts on public APIs | Yes — @requires / @ensures, three-tier discharge | No — assert!() at runtime only | F* and SPARK have done this; Rust has not. |
| No executable build scripts | Yes — declarative manifest only | No — build.rs, proc_macro, async/await runtime macros | Source of every Rust supply-chain incident of 2025-26. |
| Central registry | No — git URLs with sha256 + cosign | Yes — crates.io | Account-compromise threat surface. |
| Stripped 'hello' binary | 53 KB | 342 KB | fastC 6.4× smaller — measured on M3. |
| Compile time to release binary | ~30–40% faster | Baseline | Measured on the cross-lang benchmark suite. |
| Inner-loop dev build | ~10 ms C step with tcc; ~160 ms without | cargo check in seconds-to-minutes | Structural to monomorphization fan-out. |
| Cross-compile setup | One `brew install zig`; 8 presets via `--target=` | rustup target add + sysroot per target | Zig wins here too. |
| Provenance on releases | Sigstore + SLSA L3 from day one | Project-by-project; not enforced ecosystem-wide | fastC structural. |
| Ecosystem size | 5 curated modules in fastc-core (1.8 launch) | 150K+ crates | Rust wins on breadth, by a lot. |
| Token efficiency for agents | Smaller surface, no lifetimes / GATs / async to express | Larger surface, lifetime annotations expensive | Stage 1.2 benchmarks; methodology open. |
| Async / await | Stage 2.3 (deferred); sync today | Yes — but pin / Send / Sync are hard | Rust wins for async-heavy work today. |
| Borrow checking | Weaker — runtime traps + contracts | Borrow checker, no equal | Rust wins; we are honest about this. |
Where fastC wins
fastC wins where the threat model is supply chain, agent-generated code, capability auditing, and small deployable binaries. The structural choices (no build scripts, caps in the type system, contracts as obligations, vendored deps with cosign) cannot be retrofitted onto Rust without breaking the ecosystem.
Where Rust wins
Rust wins where the threat model is memory safety as a hard guarantee, async-heavy I/O code, or ecosystem breadth. The borrow checker is the gold standard; fastC's contracts plus runtime traps are weaker on that axis. For team-internal services with extreme correctness requirements on shared-mutable-state concurrency, Rust is the better tool.
The honest framing
If your team can credibly enforce 'no build.rs, no proc macros, no async, curated deps, comments-as-contracts' on top of Rust forever, you should — Rust is a fine language. fastC is for the case where you cannot, or where you want the enforcement to come from the language rather than the policy.