Why a new systems language?

The thesis

Today's systems languages were designed when both ends of that bottleneck looked different. C assumed a careful human writing every line. Rust assumed a careful human navigating a borrow checker, with a 150,000-crate ecosystem stitched together by macros that run during the build. Zig assumed a careful human using comptime to express what the type system could not.

None of these languages were designed for a world where the producer of code is a stochastic process and the verifier is also a stochastic process — but the compiler is the only deterministic step in the loop.

fastC is the systems language for that world.

What we commit to

1. Zero executable build scripts. Dependencies are git URLs with commit + sha256 + cosign keyless signing, vendored into the project tree. No build.rs, no build.zig, no cgo, no proc_macro, no postinstall. The package manifest is declarative.
2. Capabilities in the type system. fs.read, net.connect(host), net.listen(port), proc.spawn, time.read, rand, env.read — a finite, named set. Capabilities are typed values passed as function arguments, minted only in main via caps::init(). A function declaring no capabilities structurally cannot do I/O.
3. Mandatory contracts on public APIs. @requires and @ensures are compile-time obligations. Three-tier discharge: a syntactic pass catches the free wins, Z3 handles linear-integer tautologies under a 500 ms per-obligation budget, and anything unproven falls back to a runtime fc_trap. Proven obligations cost zero at runtime.
4. A measured compile-time budget enforced in CI. Not "fast." Numbers, published, regressed against on every push. fastc build --dev swaps in tcc for sub-10 ms inner-loop C steps.
5. Sigstore + SLSA L3 from day one. The compiler binary ships with cosign-keyless signatures and SLSA Level 3 provenance. The binary you run cannot be silently swapped out.
6. One curated answer per domain. The fastc-core launch set ships five batteries-included modules: cli, log, json, toml, http. No researching the current idiomatic logging crate.

What we are not committing to

• SMT-discharged contracts in v1. Stage 2.1, after the runtime tier has shaken out the surface syntax. We have read enough F* and SPARK Ada to know SMT UX is the hardest part of the design.
• A package registry server. fastc.dev is a search frontend over GitHub. No service to run, no account to compromise, no domain to phish.
• Async / await in the initial milestones. Stage 2.3, and only because capability typing makes async = caps(net | time) a clean expression.
• Ingesting arbitrary C source. fastC emits C. It does not parse C. Zig is better at that, on purpose, with a different threat model.
• Beating Rust at safety or Zig at explicitness on every axis. The argument is not "fastC is better on every dimension." The argument is that fastC is the only language that combines capability-typed I/O, mandatory contracts, zero executable build scripts, capability-aware deps with mandatory provenance, and a CI-enforced compile-time budget.

Who is building this

fastC is a research project of Skelf-Research, an applied programming-languages lab. The compiler is written in Rust (~1.85+), emits portable C11, and is MIT-licensed. Documentation lives at docs.skelfresearch.com/fastc/.

How to participate

• If you are building agent infrastructure: try generating fastC code via fastc-mcp instead of text-parsing cargo check output. Measure the token cost and first-compile success rate.
• If you own supply-chain security on a Rust or Zig codebase: read docs.skelfresearch.com/fastc/why/ and tell us what is missing from the threat model.
• If you are skeptical of any specific claim — the capability lattice, the compile-time budget, the SMT timeout strategy, the choice of tcc for dev builds — open an issue with a counter-argument. We will write a response and either update the design or document why the existing one stands.

---

MIT-licensed. Source: github.com/Skelf-Research/fastc. Docs: docs.skelfresearch.com/fastc/.