Honest roadmap
Familiar code. Native execution. A path to deeper control.
Turbo is not trying to claim every native market at once. The near wedge is approachable native tooling, local/system-adjacent backends, small services, and compute workers. The long-term ambition is Rust-class speed and memory control without making every program start at Rust's complexity ceiling.
Where Turbo fits
The market is clearest where TypeScript-shaped ergonomics meet the practical value of a native binary: fast local tools, compact deployment artifacts, and code that can later expose more control when profiling proves it needs it.
Strongest fit now
- • Native CLIs and developer tools
- • Local data-processing utilities
- • Small HTTP/JSON services
- • Compute workers where startup and packaging matter
Promising, with gaps to close
- • Task servers and durable workers
- • API-heavy SaaS backends
- • Embedded-style single binaries
- • 2D tools, simulations, and game-adjacent pipelines
Future gates, not current claims
- • Native macOS, Linux, and Windows GUI apps
- • Realtime game engines
- • Kernel, driver, and freestanding system software
- • Untrusted sandbox execution
Roadmap lanes
Shipped foundation
Familiar language core
Type inference, functions, structs, enums, pattern matching, generics, traits, Result/Optional shapes, string interpolation, JIT run, AOT build, tests, formatter, REPL, LSP, HTTP, JSON, SQLite, threads, channels, and mutexes form the current public surface.
Current release closeout
Correctness before bigger claims
The release line is focused on semantics that must be boring: JSON text preservation, ownership around recursive values, AOT/JIT parity, fail-closed benchmarking, and explicit limits where the runtime does not yet cover a platform or edge case.
Next performance lane
Close the Rust gap with measured compiler/runtime work
The next optimizations are representation and allocation driven: compact value layouts, typed lowering, Option/Result specialization, string and hashmap hot paths, fewer ARC operations, and benchmark cases long enough to qualify on macOS ARM64 and Linux x86_64.
Next control lane
Progressive memory control
Turbo should stay approachable by default, then reveal lower-level tools when needed: cost attribution first, borrowed views and owned buffers next, then explicit no-allocation regions that can prove zero allocations after warmup in controlled code.
Server lane
From small services to task servers
The server story needs TLS/client HTTP, bounded concurrency, cancellation, backpressure, streaming, better request/response types, durable-worker patterns, and operational examples before Turbo claims broad backend readiness.
Platform lane
Desktop, games, and systems only after bindings and frame evidence
Turbo can already express game-like simulations and native process work, but real GUI/game/system claims need stable FFI, platform bindings, frame-time benchmarks, asset/tooling stories, Windows parity, and freestanding/runtime boundaries.
Performance goals
These are targets, not guarantees. They become claims only after the accepted harness proves them with comparable algorithms, output oracles, repeated paired runs, confidence intervals, and required host coverage.
- Managed Turbo CPU geometric mean ≤1.15× Rust on the accepted benchmark suite.
- Controlled Turbo CPU geometric mean ≤1.05× Rust where lower-level controls are used.
- No individual CPU workload above 1.35× managed or 1.15× controlled.
- Live payload memory ≤1.25× Rust managed and ≤1.10× Rust controlled on defined memory workloads.
- Controlled no-allocation workloads prove exactly zero allocations and RC activity after warmup.
- Every public claim names the host, compiler flags, workload shape, output oracle, and confidence interval.
What this means for releases
Release notes should say exactly what changed and what remains limited. Turbo can be exciting without pretending that early native execution, ARC/COW memory management, and current server primitives already equal mature Rust, Go, or Node ecosystems.