The road to 1.0, and past it.

Xo is at v0.9 and still experimental. A stage is marked done when the test suite covers it. 1.0 will be a compatibility promise, and the project owner decides when Xo makes it. The order is set; there are no dates.

1. ✓

   Language design and specification

   Syntax, types, effects, and diagnostics written down as a spec, with every design choice recorded as a numbered decision.

2. ✓

   A compiler that emits Go

   The type, effect, and concurrency checker, and the Go backend: every program builds into static binaries for linux, darwin, windows, and wasi.

3. ✓

   Tools for agents

   JSON diagnostics with fixes, semantic queries and edits, a language server, concurrency tests that search task interleavings, and record and replay.

4. ✓

   Modules

   Lock files, module proxies, a checksum log, and per definition hashes that show what a release really changed.

5. ✓

   Native backends, in preview

   LLVM and a direct arm64 backend build programs to native code with no garbage collector (--no-gc).

6. ✓

   Real-time functions

   uses realtime: the compiler enforces bounded loops, no recursion, and no allocation.

7. ✓

   A front end written in Xo

   The lexer, parser, and type checker rewritten in Xo, with output identical to the Go implementation on every program in the repository, on all three backends.

8. ✓

   A playground in the browser

   The compiler and the Go toolchain run in WebAssembly, so the playground needs no server.

9. ●

   The rest of the compiler in Xo

   In progress: the SSA builder is done; the code generators follow, in the order of the plan.

10. ○

    Stability audit

    Last pass 2026-10-10: 180 of 191 spec features stable, 1 in preview, and 10 gaps, all marked for later. The next pass is queued; the gaps are closed or cut before 1.0.

11. ○

    1.0

    Code that builds keeps building. The Go backend is the supported path at 1.0; the native backends ship as preview.

12. ○

    Native backends out of preview

    After 1.0: LLVM and arm64 build the whole language without a garbage collector, with the same guarantees as the Go backend.

13. ○

    A bigger standard library

    More of what real programs need. Command line tools come first and are already in the plan below: argument parsing, running other programs, terminals, files, and common formats.

The plan, in order

One stage in flight at a time. Most stages move the compiler into Xo, each checked against the Go implementation until the output is identical; the Go implementation is retired once every backend it drives exists in Xo, so that each change is made once. The WebAssembly backend comes after, since it is written only in Xo.

1. ✓

   Front end in Xo

   The lexer, parser, and type checker give output identical to the Go compiler on all three backends: 610 of 626 repository programs (the other 16 call Go or C).

2. ✓

   SSA builder in Xo

   All 8 stages. 11,543 of 11,569 functions identical to the Go builder's SSA, and 6,282 of 6,376 in test binaries; every function left over is one the Go builder rejects too. The passes give identical output on all 306 programs both build completely, and the verifier's 32,411 mutant verdicts (one per function with a retain or release removed) match. No differences on any backend. Built with LLVM, a full run through every pass and the verifier takes 1.05x the time of the Go-built compiler (1.3x with the Go or arm64 backend); the build step alone, 1.6x to 2.3x.

3. ✓

   Supply-chain safety by default

   Only your own module vouches for a dependency's C bindings, xo.lock locks each dependency's effects, capabilities can be narrowed at run time, xo audit reports it all, and logging is an effect. Against 15 attack scenarios from the Backstabber's Knife Collection: 10 blocked.

4. ✓

   Prebuilt runtime

   Release builds ship the arm64 backend's C runtime prebuilt for each target, so arm64 builds no longer compile C: no clang needed. The system C toolchain (cc) still assembles and links the output; the LLVM backend still compiles its IR with clang. A first build on a cold cache went from 1.94 s to 0.13 s for a small program and from 4.27 s to 0.28 s for an HTTPS server (darwin/arm64). The linux/arm64 runtime is cross compiled on a Mac and reproducible byte for byte.

5. ●

   arm64 emitter in Xo, then the switch-over

   In progress, staged like the SSA builder. When the Xo compiler builds itself to a byte identical fixed point and passes the arm64 tests, the released xo on arm64 hosts becomes the self-hosted compiler for native builds.

6. ●

   Standard library for tools

   In progress. Command line parsing, running other programs, terminals, files, formats, shell completions, and version stamping, each designed in a recorded decision first.

7. ○

   LLVM emitter in Xo

   The LLVM backend's code generation moves to Xo.

8. ○

   Go code generator in Xo

   The Go backend's code generation moves to Xo. That backend keeps using the Go toolchain for your programs, use go, and Go's targets.

9. ○

   Retire the Go implementation

   Once every backend it drives exists in Xo and the full test suite passes on the self-hosted compiler, the Go implementation is retired, and each change is made once instead of twice.

10. ○

    WebAssembly backend

    SSA to .wasm, written only in Xo, so it comes after the Go implementation is retired. With it, the playground runs the Xo compiler itself, with no Go compiler or linker to download.

11. ○

    Runtime pilot, then the runtime port

    Port one small file of the C runtime to Xo and compare output and speed, then decide whether the whole runtime moves to Xo, as Go's did.

12. ○

    Supply-chain follow-ups

    Tag each log record with the dependency that wrote it, and a capability that budgets CPU time and allocation, to bring two of the five attack scenarios Xo does not block today into scope.