- Doorlooptijd27 dagen, eerste commit → v1.5
- Officiële testsuite90% van Roast
- Opstarttijd~2 milliseconden
- Draait opmacOS, Linux, Windows, de browser
Af en toe komt er een project voorbij dat beter dan welke dienstenlijst ook laat zien wat een team werkelijk kan. Raku++ is dat project voor ons.
In juli 2026 begonnen we met een lege map en een bewust moeilijk doel: een werkende compiler voor Raku — een van de grootste en meest expressieve programmeertalen die er zijn — volledig vanaf nul geschreven in C++, zonder iets anders dan de standaardbibliotheek, snel genoeg om er met plezier mee te werken, en correct genoeg om afgemeten te worden aan de officiële testsuite van de taal zelf in plaats van aan onze eigen mening erover.
Vier weken later draaide er echte productiesoftware op, compileerde het programma's tot native binaries voor drie besturingssystemen, voerde het Raku uit binnen een webbrowser, en haalde het 90% van de officiële specificatiesuite. Deze pagina vertelt het verhaal van dat werk — wat het vroeg, hoe we onszelf eerlijk hielden, en waarom dezelfde discipline is wat we meenemen naar klantprojecten.
De korte versie — tien slides
Weinig tijd? Het hele verhaal bestaat ook als presentatie. Navigeer met de pijlen, je toetsenbord of een veegbeweging:
Open de presentatie schermvullend — en daar print ⌘P / Ctrl-P hem één slide per pagina, dus een PDF is één toetsaanslag ver.
Niet één project — een hele constellatie
Een compiler op zichzelf is een curiositeit. Om nuttig te zijn heeft hij een manier nodig om geïnstalleerd te worden, om uitgeprobeerd te worden, om dingen op te zoeken, en om te bewijzen dat hij klopt. Dus groeide er een familie omheen, allemaal gebouwd uit dezelfde ene bron:
- Raku++ — de interpreter en native compiler in C++17, met een handgeschreven lexer, parser, evaluator, regex-engine, rekenen met willekeurige precisie en volledige Unicode-tabellen. Helemaal geen third-party dependencies.
- Raku.js — precies dezelfde engine gecompileerd naar WebAssembly, zodat Raku in een browsertabblad draait zonder server erachter. Geen herimplementatie: letterlijk dezelfde broncode, dus het gedrag is identiek aan de native build.
- raku.online — de publieke playground gebouwd op Raku.js, met deel-via-link en een kant-en-klare widget die elk codeblok op elke website verandert in een live, uitvoerbare editor.
- De specificatie — een gedragsspecificatie van de taal, bijna 700 pagina's verdeeld over zeventien secties, waarbij elk voorbeeld ter plekke uitvoerbaar is en de uitvoer vóór publicatie tegen de engine is geverifieerd.
- A Tour of Raku — achttien interactieve lessen, opnieuw met elk voorbeeld als live editor.
- Raku Drills — 150 oefenvragen van beginner tot expert; de invul-opgaven worden nagekeken door daadwerkelijk uit te voeren wat je hebt geschreven, in je eigen browser.
- Een testcorpus — duizenden echte Raku-programma's, speciaal verzameld zodat de compiler vergeleken kon worden met de referentie-implementatie op code die echte mensen hebben geschreven.
- Distributie — een Homebrew-tap voor macOS, een Guix-kanaal en een Nix-flake voor Linux, kant-en-klare release-archieven voor macOS, Linux en Windows, en een kant-en-klare GitHub Action voor continuous integration.
- Zelf-hostende tooling — de testharnas, de benchmarkharnas, de performance-gate en de sitegeneratoren zijn zelf in Raku geschreven en worden door Raku++ uitgevoerd. Het gereedschap dat de compiler meet, draait op de compiler.
Zoveel bewegende delen consistent houden is op zichzelf een engineeringprobleem, en een dat klanten direct herkennen: één versienummer dat uit één plek stroomt, een gedocumenteerd release-draaiboek, en de regel dat nergens stroomafwaarts een oudere engine blijft draaien.
Vier onafhankelijke meetlatten
Iedereen kan beweren dat zijn software werkt. De interessante vraag is waaraan je het afmeet — en ons antwoord was: aan vier dingen tegelijk, omdat elk van hen blind is voor wat de andere opmerken.
1. De officiële testsuite. Raku heeft een zeldzaam voordeel: zijn specificatie is uitvoerbaar. Roast, de officiële suite, bestaat uit zo'n 1.460 bestanden met uitvoerbare specificatie. We ontwikkelden er vanaf dag één test-first tegenaan. Vandaag slaagt 90% van alle individuele tests die de suite declareert — 196.395 van de 217.060. Op de veel hardere alles-of-niets-maat, waarbij één falende assertie een heel bestand diskwalificeert, slagen 625 van de 1.462 bestanden volledig. Eén hele sectie van de specificatie — Unicode en stringverwerking, het lastigst om goed te doen en het makkelijkst om te veinzen — staat op 100%: alle 91.752 asserties, inclusief 8.271 internationale collatie-conformiteitstests.
2. De officiële documentatie. Een testsuite test features geïsoleerd; documentatie laat zien hoe mensen daadwerkelijk wordt verteld ze te gebruiken. Dus haalden we elk uitvoerbaar voorbeeld uit de officiële documentatie van de taal — 1.451 stuks — draaiden ze onder zowel onze engine als de referentie-implementatie, en vergeleken de uitvoer byte voor byte. Dat getal klom release na release: 596, toen 835, toen 936, en vandaag 944 identiek. Elk gat daartussen was een echt verschil in gedrag dat we vonden, doorgrondden en dichtten.
3. Een operator-gedragsmatrix. Vervolgens dezelfde behandeling voor de operatoren van de taal: 833 expressies over 121 operatoren, elk op beide engines geëvalueerd en gedift. In één releasecyclus daalden de afwijkingen hier van 72 naar 30 — en het totaal over beide datasets ging van 202 naar 152. Verschillende van die correcties waren één enkele grondoorzaak die vijftien rijen tegelijk opruimde, precies wat je hoopt en alleen vindt door te meten.
4. Echte software, en de code van anderen. Specificaties en documentatie missen nog altijd wat echte programma's doen. Dus draaiden we echte programma's. De statische sitegenerator achter een programmeercursus van 1.500 pagina's — zelf in Raku geschreven — genereert de hele site nu byte voor byte identiek aan de referentie-implementatie. Een omvangrijk datagedreven webproject draait van begin tot eind tegen een live database. Daarnaast twee corpora: 3.068 codefragmenten uit de cursus, die 148 echte meningsverschillen aan het licht brachten die we terugbrachten tot 14; en 10.428 oplossingen uit de gemeenschap uit jaren van een publieke wekelijkse programmeeruitdaging — duizenden kleine, zeer uiteenlopende programma's van vele handen, door dezelfde vergelijk-en-diff-slag gehaald.
Dat laatste front zouden we aanraden aan iedereen die een compatibiliteitskritisch systeem oplevert. Elke meetlat heeft een blinde vlek die de andere afdekken, en ze allemaal draaien — en telkens vertrouwen op degene die op dat moment naar een probleem wijst — is wat het werk eerlijk hield.
Die methode beschreven we op een eigen pagina, met de echte dashboards en grafieken: Gemeten, niet gegokt — ontwikkeling gestuurd door cijfers.
Cyclus na cyclus na cyclus
Niets hiervan kwam uit een verlanglijstje. Het kwam uit een lus die nooit veranderde: vind wat faalt, begrijp wat de taal werkelijk bedoelt vanuit de specificatie en de tekst, maak de kleinste verandering die echt juist is in plaats van eentje die alleen een test groen maakt, draai alles opnieuw, en schrijf op wat niet vanzelfsprekend was.
Op dat tempo volgen releases elkaar snel op — een dozijn getagde versies in vier weken, elk afgeschermd door de volledige suite, zonder toegestane regressies. En de lus is niet beter dan de discipline eromheen:
- We publiceren het onflatteuze getal. Er zijn drie verdedigbare manieren om het slagingspercentage te berekenen; wij zetten de strengste in de kop. Zowel het per-test- als het per-bestand-cijfer wordt altijd samen genoemd, met de methodologie zwart op wit.
- Het doel wijkt terug naarmate je beter wordt. Hoe beter de compiler, hoe verder kapotte bestanden komen voordat ze falen — dus declareren ze meer tests, en groeit de noemer. Dat hebben we gedocumenteerd in plaats van stilletjes een vriendelijkere basislijn te kiezen.
- Soms verlaagt de juiste fix de score. Meer dan eens legde een correctheidsfix een test bloot die per ongeluk slaagde. Dan houden we de fix, herijken we, en zeggen we dat erbij.
- Opgeloste bugs blijven opgelost. Elk gesloten defect wordt een regressietest — inmiddels 149 — en geen enkele release gaat uit zonder ze allemaal te doorstaan.
- Performance is een poort, geen hoop. Een release kán geen snelheidsregressie bevatten: een vastgelegde basislijn wordt automatisch opnieuw gemeten en laat de build falen.
- We schrijven op wat niet werkte. Optimalisaties die gemeten en verworpen zijn, staan naast de geslaagde beschreven, zodat niemand — wijzelf over een half jaar incluis — er nog een week aan verspilt.
Snelheid: het deel dat je echt merkt
Het doel was vanaf dag één niet alleen "correct" maar "zo snel dat je ernaar grijpt". Twee getallen doen er het meest toe.
De opstarttijd is vrijwel nul. Raku++ is een kleine native binary zonder virtuele machine die moet opstarten: hij start in ongeveer 2 milliseconden (beste van 200 starts: 1,8 ms). Bij één run is dat onzichtbaar. Bij de tweehonderdste run van een bewerk-en-genereer-lus, of in een shellscript dat hem in een lus aanroept, is het het verschil tussen gereedschap dat je denken onderbreekt en gereedschap dat dat niet doet. Engines die een runtime met zich meedragen besteden doorgaans een flinke fractie van een seconde voordat je eerste regel wordt uitgevoerd.
En de programma's zelf zijn snel. Op een reeks benchmarkkernels die beide engines identiek draaien, verslaat onze interpreter de volwassen referentie-implementatie al op zeven van de negen. Het programma compileren naar een native binary — één enkele command-line-vlag — zet hem op alle negen voorop:
| Benchmark | Raku++, gecompileerd | Referentie-engine | Sneller |
|---|---|---|---|
| Strings opbouwen | 3,8 ms | 181,5 ms | 47,8× |
| Hash-bewerkingen | 17,6 ms | 226,3 ms | 12,9× |
| Numerieke lus | 29,1 ms | 265,8 ms | 9,1× |
| Rekenen met grote getallen | 30,5 ms | 252,1 ms | 8,3× |
| Stringvergelijking | 51,3 ms | 300,1 ms | 5,8× |
| Sorteren | 51,7 ms | 251,1 ms | 4,9× |
| Reguliere expressies | 67,8 ms | 278,8 ms | 4,1× |
Beste van zes runs op dezelfde machine, inclusief procesopstart; het harnas controleert dat alle engines byte-identieke uitvoer geven vóórdat er iets getimed wordt. De volledige methodologie is samen met de cijfers gepubliceerd.
Die cijfers kwamen niet toevallig tot stand. Ze kwamen uit profiling en meedogenloze opvolging: één late optimalisatieronde rangschikte vijf kandidaten op basis van een profiel, voerde er drie door, mat en verwierp er één, en mat er één die bewust nooit is geprobeerd — en maakte onderweg recursieve functieaanroepen 17,6% sneller, puur door data niet te kopiëren die toch weggegooid ging worden.
Eén klein voorbeeld maakt het punt beter dan welke benchmark ook. De cursussite kleurt zijn codevoorbeelden met een veelgebruikte Python-tool die — zoals bijna alle syntax-highlighters — werkt door woorden te matchen, en dus een methode met de naam role kleurt alsof het een sleutelwoord is. Raku++ parseert de code echt, en kent het verschil dus structureel. Het produceert exact hetzelfde uitvoerformaat, is direct inwisselbaar, is simpelweg correcter — en doet het werk in 13 milliseconden waar de vorige tool er 110 nodig had.
Overal uitrollen
Uitlevering werd als volwaardige feature behandeld, niet als bijzaak. Een Raku-programma kan op vier manieren vanuit dezelfde binary draaien — geïnterpreteerd, of gecompileerd tot een zelfstandige executable via drie steeds agressievere strategieën, waarvan de sterkste het programma vertaalt naar C++ en native compileert. Het resultaat is één op zichzelf staand bestand, zonder runtime die ernaast geïnstalleerd moet worden.
- macOS — één universele binary voor zowel Apple Silicon als Intel, te installeren met één Homebrew-commando.
- Linux — een statisch gelinkte build zonder runtime-afhankelijkheden, plus een Guix-kanaal en een Nix-flake voor distributies die vanaf de bron willen bouwen.
- Windows — een statische build die geen redistributable-pakketten nodig heeft.
- De browser — dezelfde engine als WebAssembly, client-side draaiend zonder dat er iets naar een server gaat.
Elke push wordt automatisch gebouwd en getest op alle drie de desktopplatformen. In de hier beschreven periode kwam er nog een besturingssysteem als release-doel bij, en externe bijdragers begonnen eigen packaging in te sturen — het Guix-kanaal arriveerde als pull request van iemand die we nog nooit hadden ontmoet. Dat bewijst op zijn eigen manier iets: de codebase is schoon genoeg om vreemden erin te laten werken.
Waarom dit op onze softwarepagina staat
Raku++ is open source en gratis, en we bouwden het niet voor een klant. We bouwden het omdat het de zwaarste, meest complete demonstratie is die we konden geven van wat ons team op een werkdag doet:
- Greenfield systems engineering in modern C++, zonder dependencies en zonder shortcuts
- Performancewerk gedreven door meten en profileren — niet door gokwerk, en hoe dan ook gedocumenteerd
- Correctheid getoetst aan een externe standaard, met de cijfers eerlijk gepubliceerd
- Cross-platform oplevering en packaging die gebruikers ook echt bereikt, op vier platformen tegelijk
- WebAssembly, zodat dezelfde kern native én in een browser draait zonder tweede implementatie
- Documentatie, tooling en releaseproces behandeld als onderdeel van het product
- Een hoog tempo — een dozijn releases in vier weken — zonder één ongedekte regressie
Als iets daarvan beschrijft wat jouw project nodig heeft — een veeleisend stuk kernsoftware, een systeem dat aantoonbaar correct moet zijn, of een bestaand product dat te traag is geworden — dan is dat precies het werk waar we het liefst aan beginnen.
Zie ook: de Raku++-productpagina, de raku.online-playground, en onze gratis Raku-cursus, waarvan elk voorbeeld op deze engine in de browser draait.