- Timeline27 days, first commit → v1.5
- Official test suite90% of Roast
- Cold start~2 milliseconds
- Ships tomacOS, Linux, Windows, the browser
Every so often a project comes along that shows, better than any list of services could, what a team is actually able to do. Raku++ is ours.
In July 2026 we started with an empty directory and a deliberately hard goal: a working compiler for Raku — one of the largest and most expressive programming languages in existence — written from scratch in C++, depending on nothing but the standard library, fast enough to be genuinely pleasant to use, and correct enough to be measured against the language's own official test suite rather than against our own opinion of it.
Four weeks later it was running real production software, compiling programs into native binaries for three operating systems, executing Raku inside a web browser, and passing 90% of the official specification suite. This page is the story of that work — what it took, how we kept ourselves honest, and why the same discipline is what we bring to client projects.
The short version — ten slides
Short on time? The whole story is also a deck. Move with the arrows, your keyboard, or a swipe:
Open the deck full screen — and once there, ⌘P / Ctrl-P prints it one slide per page, so a PDF is a keystroke away.
Not one project — a whole constellation
A compiler on its own is a curiosity. To be useful it needs a way to install it, a way to try it, a way to look things up, and a way to prove it is right. So the compiler grew a family around it, all built from the same single source:
- Raku++ — the interpreter and native compiler in C++17, with a hand-written lexer, parser, evaluator, regular-expression engine, arbitrary-precision arithmetic, and full Unicode tables. No third-party dependencies at all.
- Raku.js — the very same engine compiled to WebAssembly, so that Raku runs inside a browser tab with no server behind it. Not a reimplementation: literally the same source, so it behaves identically to the native build.
- raku.online — the public playground built on Raku.js, with a share-by-link feature and a drop-in widget that turns any code block on any website into a live, runnable editor.
- The specification — a behavioural specification of the language, close to 700 pages across seventeen sections, where every single example is runnable in place and its output verified against the engine before publication.
- A Tour of Raku — eighteen interactive lessons, again with every example a live editor.
- Raku Drills — 150 practice questions graded from beginner to expert; the fill-in-the-code ones are marked by actually running what you wrote, in your own browser.
- A test corpus — thousands of real-world Raku programs, collected specifically so the compiler could be compared against the reference implementation on code that real people wrote.
- Distribution — a Homebrew tap for macOS, a Guix channel and a Nix flake for Linux, prebuilt release archives for macOS, Linux, and Windows, and a ready-made GitHub Action for continuous integration.
- Self-hosted tooling — the test harness, the benchmark harness, the performance gate, and the site generators are themselves written in Raku and executed by Raku++. The tool that measures the compiler runs on the compiler.
Keeping that many moving parts consistent is its own engineering problem, and one clients recognise instantly: a version number that flows from a single place, a documented release runbook, and a rule that nothing downstream is ever left running an older engine.
Four independent yardsticks
Anyone can claim their software works. The interesting question is what you measure it against — and our answer was: against four things at once, because each one is blind to what the others catch.
1. The official test suite. Raku has a rare advantage: its specification is executable. Roast, the official suite, is around 1,460 files of runnable specification. We developed test-first against it from day one. Today 90% of every individual test the suite declares passes — 196,395 of 217,060. On the much harsher all-or-nothing measure, where a single failing assertion disqualifies an entire file, 625 of 1,462 files pass completely. One whole section of the specification — Unicode and string handling, the hardest to get right and the easiest to fake — passes at 100%: all 91,752 assertions, including 8,271 international collation conformance tests.
2. The official documentation. A test suite tests features in isolation; documentation shows how people are actually told to use them. So we extracted every runnable example from the language's official documentation — 1,451 of them — ran each one under both our engine and the reference implementation, and compared the output byte for byte. That number climbed release by release: 596, then 835, then 936, and 944 identical today. Every gap in between was a real behavioural difference that we found, diagnosed, and closed.
3. An operator behaviour matrix. Then the same treatment for the language's operators: 833 expressions across 121 operators, each evaluated on both engines and diffed. In a single release cycle the divergences here dropped from 72 to 30 — and the total tracked across both data sets went from 202 down to 152. Several of those fixes were single root causes that cleared fifteen rows at once, which is exactly what you hope for and only find by measuring.
4. Real software, and other people's code. Specifications and documentation still miss what real programs do. So we ran real programs. The static-site generator behind a 1,500-page programming course — itself written in Raku — now regenerates the entire site byte-for-byte identically to the reference implementation. A substantial data-driven web project runs end to end against a live database. Beyond that, two corpora: 3,068 code snippets from the course, which surfaced 148 genuine disagreements that we drove down to 14; and 10,428 community solutions from years of a public weekly programming challenge — thousands of small, wildly varied programs written by many hands, run through the same compare-and-diff sweep.
That last front is the one we would recommend to anybody shipping a compatibility-critical system. Each yardstick has a blind spot the others cover, and running all of them — trusting whichever one is currently pointing at a problem — is what kept the work honest.
We wrote up that method on its own page, with the actual dashboards and graphs: Measured, not guessed — development guided by numbers.
Cycle after cycle after cycle
None of this came from a wishlist. It came from a loop that never changed: find the failing thing, understand what the language actually means from the specification and the prose, make the smallest change that is genuinely right rather than one that merely turns a test green, re-run everything, and write down what was non-obvious.
Run at that cadence, releases come fast — a dozen tagged versions in four weeks, each one gated on the full suite with zero regressions permitted. And the loop is only as good as the discipline around it:
- We publish the unflattering number. There are three defensible ways to compute the pass rate; we headline the strictest one. Both the per-test and the whole-file figures are always quoted together, with the methodology written down.
- The target moves away from you as you improve. The better the compiler gets, the further broken files run before failing — so they declare more tests, and the denominator grows. We documented that rather than quietly picking a friendlier baseline.
- Sometimes the right fix lowers the score. More than once a correctness fix exposed a test that had been passing by accident. We keep the fix, re-baseline, and say so.
- Fixed bugs stay fixed. Every closed defect becomes a regression test — 149 of them and counting — and no release ships without passing all of them.
- Performance is a gate, not a hope. A release literally cannot ship a speed regression: a recorded baseline is re-measured automatically and fails the build.
- We write down what did not work. Optimisations that were measured and rejected are documented alongside the ones that landed, so nobody — including us in six months — burns a week retrying them.
Speed: the part you actually feel
The goal from day one was not merely "correct" but "fast enough that you reach for it." Two numbers matter most.
Startup time is essentially zero. Raku++ is a small native binary with no virtual machine to boot: it starts in about 2 milliseconds (best of a 200-launch loop: 1.8 ms). On a single run that is invisible. On the two-hundredth run of an edit-and-regenerate loop, or in a shell script that calls it in a loop, it is the difference between a tool that interrupts your thinking and one that doesn't. Engines that carry a runtime with them typically spend a good fraction of a second before your first line executes.
And the programs themselves are fast. On a set of benchmark kernels that both engines run identically, our interpreter already beats the mature reference implementation on seven of nine. Compiling the program to a native binary — a single command-line flag — puts it ahead on all nine:
| Benchmark | Raku++, compiled | Reference engine | Speed-up |
|---|---|---|---|
| String building | 3.8 ms | 181.5 ms | 47.8× |
| Hash operations | 17.6 ms | 226.3 ms | 12.9× |
| Numeric loop | 29.1 ms | 265.8 ms | 9.1× |
| Big-number arithmetic | 30.5 ms | 252.1 ms | 8.3× |
| String comparison | 51.3 ms | 300.1 ms | 5.8× |
| Sorting | 51.7 ms | 251.1 ms | 4.9× |
| Regular expressions | 67.8 ms | 278.8 ms | 4.1× |
Best of six runs on the same machine, process startup included; the harness verifies that all engines produce byte-identical output before it times anything. Full methodology is published alongside the numbers.
Those figures did not arrive by accident. They came from profiling and from ruthless follow-up: one late optimisation round ranked five candidates from a profile, landed three, measured and abandoned one, and measured and deliberately never attempted another — and made recursive function calls 17.6% faster in the process, purely by not copying data that was about to be thrown away.
One small example makes the point better than any benchmark. The course site highlights its code samples with a widely used Python tool, which — like nearly all syntax highlighters — works by pattern-matching words, and so paints a method named role as if it were a keyword. Raku++ genuinely parses the code, so it knows the difference structurally. It emits exactly the same output format, drops straight in as a replacement, is simply more correct — and does the job in 13 milliseconds where the previous tool took 110.
Ship it anywhere
Delivery was treated as a first-class feature rather than an afterthought. A Raku program can be run four ways from the same binary — interpreted, or compiled into a standalone executable by three progressively more aggressive strategies, the strongest of which translates the program into C++ and compiles it natively. The result is a single self-contained file with no runtime to install alongside it.
- macOS — one universal binary covering both Apple Silicon and Intel, installable with a single Homebrew command.
- Linux — a statically linked build with no runtime dependencies, plus a Guix channel and a Nix flake for distributions that need to build from source.
- Windows — a static build needing no redistributable packages.
- The browser — the same engine as WebAssembly, running client-side with nothing sent to a server.
Every push is built and smoke-tested on all three desktop platforms automatically. A further operating system was added as a release target during the period described here, and outside contributors have started sending packaging of their own — the Guix channel arrived as a pull request from someone we had never met. That is its own kind of proof: the codebase is clean enough for strangers to work in.
Why this sits on our software page
Raku++ is open source and free, and we did not build it for a client. We built it because it is the hardest, most complete demonstration we could give of what our team does on a working day:
- Greenfield systems engineering in modern C++, with zero dependencies and no shortcuts
- Performance work driven by measurement and profiling — not by guesswork, and documented either way
- Correctness held to an external standard, with the numbers published honestly
- Cross-platform delivery and packaging that actually reaches users, on four platforms at once
- WebAssembly, so the same core runs natively and in a browser without a second implementation
- Documentation, tooling, and release process treated as part of the product
- A fast cadence — a dozen releases in four weeks — without a single unguarded regression
If any of that describes what your project needs — a demanding piece of core software, a system that has to be provably correct, or an existing product that has become too slow — that is precisely the work we like most.
See also: the Raku++ product page, the raku.online playground, and our free Raku course, whose every example runs in the browser on this engine.