Ruby's founding bargain has always been the same: give up static guarantees, gain metaprogramming, and accept that an interpreter is the price. Yukihiro "Matz" Matsumoto has now published a compiler that takes the other side of that bargain — and the numbers are not marginal.
Spinel, on GitHub under the MIT licence, compiles Ruby source into a standalone native executable. It parses with libprism, runs whole-program type inference to a fixed point, emits a single C file and hands it to the system `cc`. The result needs libc and libm and nothing else: no Ruby runtime, no gems loaded at start-up. The compiler itself is one self-contained C binary — no shell wrapper, no chained helper processes.
According to the repository's benchmark table, measured on 2026-09-17 on a 32-core Linux box with gcc 13.3, Spinel is a geometric mean of roughly 8.5x faster than CRuby 4.0.4 run with `--yjit` across 28 benchmarks, and about 15.2x against the plain interpreter. Mandelbrot lands at 18 ms against 938 ms; the ao_render ray tracer at 70 ms against 611 ms with YJIT. A compiled binary starts in about 0.8 ms. The repo reports 3,651 tests and 62 benchmarks passing.
The project is unusually honest about where those numbers come from. Recursive fib looks 44.6x faster, and the README says outright why: its whole call tree is a pure function of a literal, so the C compiler folds most of it away. The narrow cells are named too — io_wordcount at 3.1x, bound by line reading and hash updates; csv_process and gcbench bound by allocation.
Where Spinel finds its speed is where it takes things away. Types are inferred across the entire program, which lets it promote small immutable classes — up to eight scalar fields — into stack-allocated C structs and skip the collector entirely; the README cites a million allocations of a five-field class falling from 85 ms to 2 ms. Short methods get inlined, loop-invariant `arr.length` is hoisted, and chains like `a + b + c + d` collapse into a single allocation. Threads are real: an M:N scheduler over OS workers, no GVL, work stealing, a ~10 ms preemption quantum — and, as in JRuby, unsynchronised shared mutation is a data race.
The bill arrives as a list of limitations. No `eval`, no `instance_eval`/`class_eval` with strings. No `method_missing`, no `define_method` or `send` with a runtime-computed name, though the literal forms work. No encodings beyond UTF-8/ASCII. Integers are native fixed-width words, and `--int-overflow` chooses between raising, wrapping silently, or promoting to a Bignum.
The tooling has grown past a compiler. `spin new` scaffolds a project, `spin add` resolves dependencies from a package index, `spin test` runs snapshot tests with CRuby as the oracle. Packages are source trees compiled into the binary, so there is no runtime loading and no extension build step. `spinel diff` runs a program under both CRuby and Spinel and labels the difference — compile-error, crash, output-diff, nondeterministic — which is precisely the instrument a compiler for a dynamic language needs before anyone trusts it with production code.
Portability is the honest limit. Linux and macOS are supported; BSD is expected to work but is not in CI; Windows means WSL. The runtime leans on POSIX assumptions — pthreads, `<sys/mman.h>` for the regexp engine, GCC's `__attribute__((cleanup))` for GC roots, inline assembly for the fiber context switch.
There are already signs this is not a toy. An adjacent project, roundhouse, transpiles Rails applications into plain Ruby; the README reports that 37signals' Campfire passes its own test suite in full under Spinel and that current upstream Lobsters compiles and links.
Spinel is not a drop-in replacement for Ruby and its author does not pretend otherwise — the README points at `docs/limitations.md` rather than a promise. But it puts a number on a question Ruby users have asked for three decades: what would this language cost if the compiler knew the types? For programs that fit inside the subset, the answer is a native binary that starts in under a millisecond and runs with no interpreter in the loop.
The repository's commit trailers also disclose an AI co-author on the maintainer's own AI-assisted commits — a detail that sits oddly next to the benchmark tables, and says something about how a language implementation gets written in 2026.
