fastc-lang · language project · v1.0 feature-complete
C, but safe and
agent-friendly.
fastC is a small systems language with capability-typed I/O, mandatory contracts, and zero executable build scripts. It compiles to portable C11. A function with no capability arguments structurally cannot do I/O — not because a sandbox blocked it, because the compiler rejected the call.
// hello.fc — a fastC program is plain C-shaped, but with
// explicit types everywhere and no implicit conversions.
fn add(a: i32, b: i32) -> i32 {
return (a + b);
}
fn main() -> i32 {
let x: i32 = 10;
let y: i32 = 20;
let result: i32 = add(x, y);
return result;
}
What is fastC
A small systems language for the age of agent-generated code.
fastC is a systems programming language that looks like C —
fn, let, i32, braces, semicolons — and
compiles to readable, portable C11 you can audit. What changes is everything
around the function body: the signature now carries
capabilities (what I/O it may do), contracts
(what must hold on entry and exit), and a fixed set of
annotations the compiler treats as obligations.
The bet: when the modal author of code is a stochastic process and the reviewer is also stochastic, the compiler is the only deterministic step in the loop — so the language should push as much of "is this correct and safe?" into the type system as it can. Read the full thesis →
Why a new language
The producer is stochastic. So is the reviewer.
Existing systems languages were designed when a careful human wrote every line. That is no longer the common case — and the properties that would help most are exactly the ones a large, established ecosystem cannot retrofit.
Problem Ambient authority & opaque builds
- Any function can call
fs::read— authority is invisible in the signature. - Build scripts (
build.rs,build.zig,cgo, postinstall) run untrusted code at build time. - Correctness lives in prose and tests, not in obligations the compiler checks.
- Diagnostics differ per tool, so agents text-parse compiler stderr.
fastC Authority in the type system
- I/O is a typed argument; a function with no capability param is structurally inert.
- No executable build scripts — deps are git URLs pinned by commit + sha256, cosign-signed, vendored.
@requires/@ensuresare compile-time obligations, discharged in three tiers.- One JSON diagnostic envelope across every error kind, read by
fastc explain.
The wedge
Four things a large ecosystem cannot retrofit.
fastC is not "Rust minus features." It is a smaller language designed from the start around properties that a 150K-package ecosystem cannot adopt without breaking itself.
The shape of a fastC program
Looks like C. Behaves like a proof obligation.
Three real fastC snippets: capabilities as typed arguments, contracts the compiler holds you to, and the v1.3 annotations an agent reads before generating a call site.
I/O as a typed argument, not ambient authority
// I/O capabilities are typed function arguments. A function
// without a CapFsRead in its signature structurally cannot
// read a file. The compiler refuses the call.
use caps::init;
fn count_files_read(c: ref(CapFsRead)) -> i32 {
discard(c);
return 42;
}
fn main() -> i32 {
let caps: Caps = init(); // root caps minted in main
let n: i32 = count_files_read(addr(caps.fs_read));
return n;
} CapFsRead, CapNetConnect, CapProcSpawn —
the capability set is finite, named, and only mintable in main via
caps::init().
Capabilities reference →
Contracts the compiler holds you to
// Pre- and postconditions are compile-time obligations.
// v1 lowers to runtime asserts; v2.1 discharges via Z3 where
// it can — proven obligations cost zero at runtime.
@requires(divisor != 0)
@requires(divisor > 0)
fn safe_div(value: i32, divisor: i32) -> i32 {
return (value / divisor);
}
@ensures(result >= 0)
fn abs(x: i32) -> i32 {
if (x < 0) {
return (0 - x);
}
return x;
}
Three-tier discharge: a syntactic pass catches free wins, Z3 handles
linear-integer tautologies under a 500 ms budget, and anything unproven falls
back to a runtime fc_trap.
Contracts reference →
Structured annotations the v1.3 surface enforces
// v1.3 added structured annotations the compiler enforces and
// `fastc explain` surfaces as JSON for agent tooling.
@purity(pure)
@complexity(O(n))
fn sum_n(n: i32) -> i32 {
let mut acc: i32 = 0;
let mut i: i32 = 0;
while (i < n) {
acc = (acc + i);
i = (i + 1);
}
return acc;
}
The v1.3 annotation set — @purity, @panics,
@complexity, @mem, plus module-level mandatory headers —
is the signature contract an agent reads before generating a call site.
fastc explain --json emits the full surface per function.
Annotations reference →
Measured
Binary size, where the wedge is sharpest.
Snapshot from the cross-language benchmark suite on M3 (2026-05-22). fastC sits in the C / Zig class, not the Rust / Go class.
| Language | hello | sum | fib(40) | mandelbrot | vs fastC |
|---|---|---|---|---|---|
| C | 33 KB | 17 KB | 17 KB | 33 KB | 0.3–0.6× |
| Zig | 50 KB | 50 KB | 50 KB | 50 KB | 0.95× |
| fastC | 53 KB | 53 KB | 53 KB | 53 KB | 1.0× |
| Rust | 342 KB | 341 KB | 341 KB | 342 KB | 6.4× larger |
| Go | 2.4 MB | 2.1 MB | 2.1 MB | 2.1 MB | 40× larger |
Compile time runs ~30–40 % faster than Rust to a release binary. Runtime matches C on floating-point work; ~26 % slower on recursive integer (overflow-check cost). Full methodology and re-run scripts live at benchmarks/cross-lang/.
Ecosystem
One curated answer per domain.
The fastc-core ecosystem ships eleven capability-typed packages, each
with a public preview repo under github.com/fastc-lang
and a v0.1.0 release alongside fastC v1.0.
Compare
Pick your fight, fairly.
fastC is not "better than X on every axis." Each comparison shows the trade-offs honestly — where fastC wins, where the other language wins, and which threat model each was built for.
vs Rust
The obvious comparison. Rust has more safety machinery and a vastly larger
ecosystem; fastC has structural answers to build.rs, capabilities,
and compile-time budgets that Rust cannot retrofit.
vs Zig
Zig is the closest in spirit on binary size, cross-compilation, and "no hidden
control flow." fastC chooses capability typing and mandatory contracts over
comptime as the wedge for agent-generated code.
Full set: Rust · Zig · C · C++ · Go · Python · TypeScript — or the all-in-one matrix →
Questions
Straight answers.
What is fastC?
fastC is a small systems programming language with capability-typed I/O, mandatory contracts, and zero executable build scripts. It compiles to portable, readable C11, ships 53 KB stripped binaries, and is designed for a world where most code is written by an AI agent and reviewed by a human. It is v1.0 feature-complete and MIT-licensed.
What does "agent-first" mean for a programming language?
A fastC function signature declares what it may do — its required capabilities, its @requires/@ensures contracts, its purity and complexity — so an agent or a human reviewer can read a function's authority without reading its body. Diagnostics are a single structured JSON envelope, and fastc mcp exposes the build artifacts to Claude Code, Cursor, and Codex over Model Context Protocol.
How is fastC different from Rust or Zig?
fastC is not "Rust minus features." It is a smaller language built around four properties a large existing ecosystem cannot retrofit: capability-typed I/O as function arguments, mandatory contracts on public APIs, no executable build scripts with vendored content-hashed dependencies, and a CI-enforced compile-time budget. Rust has more safety machinery and a larger ecosystem; Zig is closest in spirit on binary size and cross-compilation.
Recent writing
Notes on the design.
How the language interacts with code-writing agents.
- What goes wrong when LLMs write C: the recurring bugs The bug shapes we see over and over when an agent generates C — and which of them the fastC type system structurally prevents.
- Reading fastC: side-by-side syntax with plain C A column-by-column tour. If you can read C, you can read fastC in twenty minutes — but the things that look the same do not always mean the same thing.
- Why agent-friendly is a real language design goal "Designed for LLMs" sounds like marketing. It is not. Here is the concrete list of language-design choices that change when the modal author of code is a stochastic process.
Explore
Everything on this site, one hop away.
Every section of the fastC site, linked directly. Start with the thesis, the stdlib, and the agent surface — or jump straight into the comparisons and the blog.
About fastC
The full thesis — what fastC commits to, what it deliberately does not, and why the compiler is the one deterministic step in an agent-written loop.
fastc-core stdlib
The 11-package curated ecosystem — cli, log, json, toml, http, time, base64, uuid, crypto-primitives, regex, and sqlite, one canonical answer per domain.
Agent tooling
The v1.3 agent surface — fastc fix, context,
diff, mcp, and explain --json.
Comparisons
Fair, grounded comparisons against Rust, Zig, C, C++, Go, Python, and TypeScript — plus the all-in-one matrix.
FAQ
Quotable answers on what fastC is, what agent-first means, capabilities, contracts, production-readiness, and how it compares.
Blog
Notes on the design, plus the six-part evolution series tracing fastC from a C fork to the v1.3 agent-tooling layer and the fastc-core ecosystem.
Documentation
The language guide, CLI reference, C interop, and getting-started quickstart — the full reference beyond this marketing site.
Source on GitHub
The MIT-licensed compiler — written in Rust, 340+ tests, cosign keyless + SLSA L3 provenance on every release.
Get started
Try C, but safe and agent-friendly.
fastC is v1.0 feature-complete, MIT-licensed, and ships with an 11-package curated stdlib and a v1.3 agent-tooling surface. Read the getting-started guide or clone the compiler.