# Roadmap

Xo is at v0.9 and still experimental. A stage is done when the test suite covers it; the project owner decides when Xo makes the 1.0 compatibility promise. There are no dates.

## The road to 1.0, and past it

- **Language design and specification** (done): Syntax, types, effects, and diagnostics written down as a spec, with every design choice recorded as a numbered decision.
- **A compiler that emits Go** (done): The type, effect, and concurrency checker, and the Go backend: every program builds into static binaries for linux, darwin, windows, and wasi.
- **Tools for agents** (done): JSON diagnostics with fixes, semantic queries and edits, a language server, concurrency tests that search task interleavings, and record and replay.
- **Modules** (done): Lock files, module proxies, a checksum log, and per definition hashes that show what a release really changed.
- **Native backends, in preview** (done): LLVM and a direct arm64 backend build programs to native code with no garbage collector (--no-gc).
- **Real-time functions** (done): uses realtime: the compiler enforces bounded loops, no recursion, and no allocation.
- **A front end written in Xo** (done): 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.
- **A playground in the browser** (done): The compiler and the Go toolchain run in WebAssembly, so the playground needs no server.
- **The rest of the compiler in Xo** (now): In progress: the SSA builder is done; the code generators follow, in the order of the plan.
- **Stability audit** (next): 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.
- **1.0** (next): Code that builds keeps building. The Go backend is the supported path at 1.0; the native backends ship as preview.
- **Native backends out of preview** (next): After 1.0: LLVM and arm64 build the whole language without a garbage collector, with the same guarantees as the Go backend.
- **A bigger standard library** (next): More of what real programs need. Command line tools came first and are done (see the plan below).

## The plan, in order

- **Front end in Xo** (done): 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).
- **SSA builder in Xo** (done): 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.
- **Supply-chain safety by default** (done): 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.
- **Prebuilt runtime** (done): 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.
- **arm64 emitter in Xo, then the switch-over** (now): In progress: every stage is ported, and the switch-over is next. 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.
- **Standard library for tools** (done): Typed command line flags and subcommands with generated help and shell completions (std/cli), running other programs with pipelines, terminals and colors, file handles, globs, and locks, CSV, TOML, regular expressions, and archives, and xo build --stamp for version stamping. Some parts are Go backend only for now; native builds report them as XO1201.
- **LLVM emitter in Xo** (now): In progress, staged like the arm64 emitter and running alongside it. The LLVM backend's code generation moves to Xo.
- **Go code generator in Xo** (next): 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.
- **Retire the Go implementation** (next): 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.
- **WebAssembly backend** (next): 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.
- **Runtime pilot, then the runtime port** (next): 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.
- **Supply-chain follow-ups** (next): 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.