Roadmap

The logic is simple: Phases 0–1 make the language reliable, Phase 2 keeps that reliability automatically, Phase 3 makes it useful, Phase 4 fast, Phase 5 publicly available. The phases can run partly in parallel, but you don't enter 3–5 before 0–1 are done — you can't build an ecosystem on top of panics in the foundation.

Phase 0 — Stability: closing open bugs (done)

The crash/DoS, security, and silent-incorrectness bugs from the full code review have all been fixed and shipped with regression tests. Open issues with the bug label are now 0.

What was closed, by wave:

• Wave 1 — crash/DoS: json.dec panic on malformed JSON, no request body size limit, unbounded recursion stack overflow, integer overflow panic, extract_from_table Unicode panic, no client/ai timeout.
• Wave 2 — security: non-cryptographic rand for tokens, Authorization leak on cross-origin redirect, dirty connection returned to the pool without ROLLBACK on tx error.
• Wave 3 — silent incorrectness: uniq(a, b) dropping the multi-column constraint, ai keeping only the last tool_use block, parser/lexer silent errors !x / m.0.1 / 1..n+1, db.up empty-where malformed SQL, lost repeated headers, queue handler-less busy-loop and shutdown job loss, query-string percent-decoding.

Since the review, several language features also landed: try/catch, assert + fluxon test, an interactive REPL, the par parallel fan-out primitive, and leveled log output.

Phase 1 — Hardening the language core

What separates a real language from a toy is a definite answer to any input:

• A guarantee never to panic. Every panic path in the runtime turns into a Fluxon-level error (err). To verify, the lexer / parser / json.dec are fuzzed with cargo-fuzz.
• Diagnostic quality. Every error shows line:column + a code snippet + "did you maybe mean this". This matters especially for AI agents — the more precise the error message, the faster the agent fixes itself.
• Stack trace. A runtime error shows the Fluxon-level call chain.
• Spec ↔ runtime audit. Is there a test for every sentence in the agent spec? When a discrepancy is found, either the spec or the runtime is fixed.
• Close the language gaps found in earlier real-project tests: str library gaps, dynamic indexing, time arithmetic.

Phase 2 — Reliability infrastructure

• Continuous fuzzing in CI (nightly job): lexer, parser, json, http request parsing.
• Expand the .fx e2e suite — "bad day" scenarios for each battery: network drop, DB lock, large payload.
• Benchmark suite + regression alert — a basis for the later move to a VM.
• Dogfooding harness. Give an AI agent (with a cheap model) real backend tasks and have it write them in Fluxon — every release. This method has found the most real bugs so far.

Phase 3 — Production-ready backend language

• Postgres real support (currently an Err stub) — required for the "backend language" claim. Fluxon db.* code is backend-neutral, the user code doesn't change.
• Deploy story: single binary, graceful shutdown, $PORT/secrets convention. Structured, leveled logging already landed.
• fluxon check — fast feedback for the AI agent loop. The CLI ships fluxon check <file.fx> today, but it is lex + parse only. A real static/semantic check (unbound names, arity, type-shape) is still to do.
• fluxon fmt — canonical form is the language's philosophy, so a formatter is mandatory. Still to do.
• Module ecosystem: use ./file exists; for now a firm "batteries-included is enough" stance.

Phase 4 — Performance

• Move from the tree-walking interpreter to a bytecode VM — but only after the Phase 2 benchmarks show "where it's slow".
• On the HTTP path, full async or a thread pool instead of a thread per request.

Phase 5 — Distribution and v0.1 (beta starting)

• Install / packaging: curl | sh + binaries on GitHub Releases, then crates.io (cargo install fluxon), a Homebrew tap, Snap, and a PPA.
• Documentation site + interactive playground (compiled to WASM it runs in the browser too).
• English translation — mostly done.
• Versioning the spec: the agent spec is frozen as v0.1, breaking changes only with a version bump. A "real language" means a promise that code written today still works tomorrow.
• Editor tooling: syntax highlighting (VS Code extension), then an LSP.