Blog
Notes on the language.
Field notes on what changes when agents write the systems code and humans review it. Some posts are language-design rationale; some are concrete bug-shape catalogues; some are honest comparisons against other languages.
- fastc-core — one curated answer per domain Walking through the 11 packages of the fastc-core ecosystem, the v1.0.x cutover, and why we don't want 11 competing JSON libraries.
- 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 fastC structurally prevents, converts into a build-time trap, or simply makes louder.
- 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.
- What v1.3 added — the agent-tooling layer Stage 1.3 annotations, the v1.0.x close-out — `fastc fix` / `context` / `diff`, expanded MCP, the unified diagnostic envelope.
- Supply chain + cross-compile: provenance from day one Stages 1.7 + 1.9 + the v2.0 hardening — sha256, cosign keyless, SLSA L3, eight cross-compile targets, compiler-binary reproducibility.
- The structural-safety wedge: capabilities + contracts Stages 1.4 + 1.5 + 2.1 — how fastC's two non-Rust safety claims were built.
- Building the core: stages 0.1 through 1.1 How fastC's rust harness, safety core, type system, traits, generics, and stdlib MVP got built — six months of foundational work.
- Why a new systems language in 2026? fastC's foundational thesis — what wedge it takes against C, Rust, Zig, and Go.
Subscribe via RSS or read the source at github.com/Skelf-Research/fastc.