2026 is een spannend jaar voor de Rust-compiler (en voor mij)

Om wat context te geven: wat dit jaar gebeurt, is dat meerdere verschillende initiatieven tegelijkertijd in hun laatste fasen terechtkomen. Met andere woorden: 2026 is niet per se speciaal vanwege de hoeveelheid werk die er wordt verricht, maar het is het jaar waarin we zien dat verschillende langetermijninvesteringen hun vruchten beginnen af te werpen.

De volgende solver

Waarschijnlijk het grootste project is de next generation trait solver. Dit is een herimplementatie van een groot deel van het typesysteem en is al heel lang in ontwikkeling — in verschillende vormen bijna tien jaar.

Het lost een reeks soundness bugs op en ontsluit veel functies en fixes voor langdurige problemen. Het is makkelijk om te onderschatten hoe belangrijk dit is voor de compiler. Dit werk lost een groot stuk technische schuld op waar veel compiler-ontwikkelaars jarenlang van droomden. Daarnaast stelt het een groep mensen met een fris en diepgaand begrip van het typesysteem in staat om aan nieuwe zaken te werken. De wachtrij met zaken die hierdoor worden ontблокиerd bevat veel veelvoorkomende pijnpunten van de taal, zelfs zaken die onschuldig of ongerelateerd lijken. Het bevat oplossingen voor grote problemen in async Rust en diverse beperkingen van impl Trait.

Polonius

Een ander groot project is Polonius, een nieuwe implementatie van de borrow checker, die eveneens al lange tijd in ontwikkeling is. Het zorgt ervoor dat meer code compileert en ontsluit verschillende gerelateerde functies — waaronder (hopelijk suatu dag) interne referenties. De impact op de compiler is minder groot dan bij de nieuwe solver, maar het is nog steeds een belangrijke mijlpaal.

Performance (Perf)

Mijn belangrijkste interessegebied is de performance van de compiler, en hier gebeurt momenteel veel. Na een periode van één tot twee jaar van stagnatie (althans wat betreft de resultaten), zien we plotseling veel zaken tegelijk gebeuren. Te veel zelfs, om alles uit het hoofd te onthouden, maar dit zijn de belangrijkste punten:

Parallel frontend is bijna gestabiliseerd

Dit is een zeer oud initiatief dat een paar jaar op een zijspoor stond vanwege onduidelijke blokkades. De ontwikkeling startte een paar jaar geleden opnieuw met een nieuwe contributor, @SparrowLi, en in de loop der tijd hebben meer mensen bijgedragen.

In de loop der jaren bleek dit een enorme "can of worms" te zijn. Ik heb het gevoel dat bijna niemand echt tevreden is met het ontwerp. Er lijkt echter voor de nabije toekomst geen beter alternatief te zijn en een parallelle frontend is zeer gewenst. De oplossing werd daarom simpelweg het wegwerken van een reeks irritante en complexe problemen totdat er niets meer overbleef. Het huidige projectdoel wordt aangestuurd door @petrochenkov en nadert stabilisatie.

LLVM wordt sneller

LLVM 23 zorgde voor een ondubbelzinnige en onverwacht grote positieve verandering in performance. Lange tijd waren LLVM-upgrades niet bijzonder gunstig voor de performance van rustc. Dit veranderde na de upgrade naar LLVM 10, die een enorme regressie van 10% introduceerde. @nikic, de huidige lead developer van LLVM, wees dit aan in zijn blogpost Make LLVM fast again. In dat bericht introduceerde hij ook een systeem voor het bijhouden van de LLVM-performance over tijd, geïnspireerd op het systeem dat wij voor rustc gebruiken.

Sindsdien is LLVM performance-regressies eerder gaan detecteren. De resultaten voor upgrades in rustc gingen van "minder slecht" naar "enigszins gemengd" naar "grotendeels positief met kanttekeningen". De laatste was LLVM 22, die positief scoorde op icount benchmarks, maar bijna universeel negatief op wall time.

LLVM 23 is vrijwel volledig positief. Voor zover ik weet komt dit omdat er nu meer werk wordt verricht aan het daadwerkelijk optimaliseren ervan, in plaats van het toevoegen van functies zonder rekening te houden met performance-regressies. Tegenwoordig komen de verbeteringen zowel voort uit nieuwe optimalisaties (die helpen de compiler te optimaliseren tijdens de bootstrap) als uit het feit dat LLVM zelf sneller wordt.

Veel micro-optimalisaties worden geïmplementeerd

De performance van de compiler vertoont de afgelopen maanden een gestage lijn van verbeteringen. Er is waarschijnlijk geen enkele verklaring voor, maar een combinatie van nieuwe contributors, oude contributors die meer tijd aan perf-werk kunnen besteden, en verbeteringen in tooling in combinatie met architecturale opschoningen die nieuwe mogelijkheden ontsluiten.

Door de toename van mensen in dit gebied merk ik veel kruisbestuiving, waarbij een bepaald idee rondgaat tussen verschillende mensen die geïnspireerd raken door elkaars PR's en gerelateerde zaken proberen. Ook heb ik het gevoel dat we veel beter zijn geworden in het beheren van regressies: het triëren en aanpakken ervan.

Dit is enerzijds een investering in tooling, maar gaat ook over processen en sociale structuren. Een belangrijke ontwikkeling hierin is de connectie tussen tree ops en perf triage, met name vertegenwoordigd door @JonathanBrouwer. Dit betekent dat mensen die merges beheren vaak direct de impact op de performance triëren. Dit is belangrijk omdat het de responstijd verkort, maar de connectie is ook om andere redenen nuttig. De impact op de performance bepaalt bijvoorbeeld hoe je PR's groepeert in rollups. Het blijkt dat de wet van Conway nog steeds een wet is.

Daarnaast vind ik het erg leuk om mensen te helpen bij het interpreteren van meetresultaten en het diagnosticeren van regressies. Ik merk vaak dat slechts een paar zinnen van iemand die de resultaten al jaren dagelijks bekijkt, al een grote stap zijn richting het oplossen van de regressie. Al met al heb ik het gevoel dat zorgen over compileertijd beter zijn geïntegreerd in de ontwikkeling dan ooit tevoren.

Move elimination

Dit kwam begin dit jaar onverwacht naar voren en is zeer interessant. @Amanieu stelde een MIR-optimalisatiepass voor die de compiler in staat stelt om kopieën te elimineren die LLVM moeilijk kan optimaliseren. Dit versnelt zowel de compileertijd als de runtime.

Dit is zo'n pass die logischer is om in MIR te implementeren dan in LLVM, omdat het Rust-gedeelte van de compiler betere informatie heeft over of het specifiek voor Rust geldig is om dit toe te passen. Bovendien vereist het een kleine wijziging in de MIR-semantiek. Dit is vooral relevant voor Rust omdat Rust doorgaans meer moves genereert dan C(++), wat het primaire LLVM-doel is.

Polymorfisatie

Dit ligt me bijzonder na aan het hart omdat ik de inspanningen al heel lang volg. Polymorfisatie is een van de meest impactvolle performance-optimalisaties die we zouden kunnen doen, maar het is helaas erg lastig om te implementeren.

Dit zou het derde experiment zijn waar ik van weet. Deze keer is het iets anders dan de vorige keren en is het geïnspireerd door een vergelijkbaar mechanisme in Swift. Het verschil is dat de oorspronkelijke polymorfisatie alleen bedoeld was om dubbele of redundante monomorfisaties te vermijden (dus puur een optimalisatie voor de compileertijd zonder runtime-impact), terwijl de Swift-stijl alles wil polymorfiseren en layouts van generieke parameters als argumenten wil doorgeven. Dit zal een runtime-kost hebben, dus het zal iets zijn dat je via compiler-flags kunt aanpassen.

Als mijn informatie nog actueel is, zal de next-solver polymorfisatie ook mogelijk maken op de eerder beoogde manier. In beide gevallen lopen ze tegen dezelfde problemen aan, dus het werk is voor beide nuttig. Het is ook mogelijk dat beide opties voortkomen uit deze zelfde inspanning. Hoe dan ook, dit is nog steeds een experiment met een reeks problemen die opgelost moeten worden; we zullen moeten zien hoe het uitpakt. Het projectdoel is voorgesteld en wordt aangestuurd door @camelid.

Gedeelde cache voor cargo check en cargo build

@blyxyas werkt aan een projectdoel dat het voor Cargo mogelijk maakt om artefacten te delen tussen cargo check en cargo build. Het doel is eigenlijk algemener, maar dit is waarschijnlijk het meest herkenbare resultaat. Dit is iets wat we al jaren willen, dus het is geweldig om progressie te zien.

Optie no-embed-metadata standaard ingeschakeld

Dit is al aangekondigd en zal de grootte van de target directory met 5-30% verminderen, afhankelijk van de workload.

Nieuwe cargo build-dir layout

Ook dit is al aangekondigd. Het is een project dat al enige tijd in de maak is. Net als bij de bovenstaande punten gaat het hier om een grote interne herstructurering die andere zaken ontsluit — namelijk granulaire vergrendeling (granular locking) van de target directory en cross-workspace caching.

no-link/link-only

@bjorn3 werkt aan het herstellen van de ondersteuning voor deze twee flags, die pipelining van build-scripts en proc-macros mogelijk maken. Zoals je in het voorstel kunt zien, is dit opnieuw een lijn van werk die neerkomt op het afwerken van een lijst met interne problemen en architecturale fouten totdat er plotseling iets groots wordt ontsloten.

Architectuur

Er zijn verschillende initiatieven binnen de architectuur van de compiler. Ik noem er een paar, juist om (opnieuw) te benadrukken dat grote zaken niet gebeuren door projecten die uit het niets verschijnen, maar als gevolg van aanhoudende langetermijninvesteringen in een gezond systeem.

Twee jaar geleden begon @jdonszelmann met de inspanning om de manier waarop attributen in de compiler worden gerepresenteerd en gecontroleerd te uniformeren en op te schonen. Een paar dagen geleden is het laatste overgebleven attribuut naar het nieuwe systeem overgezet. Dit verbetert aanzienlijk hoe attributen worden gecontroleerd en ontsluit verbeteringen aan diagnostics en andere zaken.

Begin dit jaar hebben @Zalathar en @nnethercote de implementatie van het query system van rustc opgeschoond. Dit verbeterde de performance, maar belangrijker nog, het maakte het systeem gemakkelijker te begrijpen, wat vaak een blokkade was voor verbeteringen. Het systeem is nog steeds een vrij angstaanjagend deel van de codebase, maar dit is een grote stap vooruit.

Er is overigens nog meer architecturaal werk in dit gebied: @oli-obk werkt aan de architecturale basis voor expansion-time evaluation, en er is veel werk verricht door @cjgilot, @petrochenkov en anderen aan queries en incremental in het algemeen.

Hetzelfde geldt voor het werk om const generics verder te laten vorderen. Een gemeenschappelijk thema in deze inspanningen is dat ze de compiler in staat stellen zijn mogelijkheden in meer contexten te gebruiken waar dat voorheen beperkt was, vaak door een strikte volgorde van bepaalde compilatiefases.

Projectdoelen en financiering

Er is ook veel "meta"-informatie. Het Rust-project experimenteert met een nieuw organisatorisch raamwerk genaamd "project goals". Na meerdere iteraties met verschillende wijzigingen en experimenten lijkt het systeem nu een optimale stabiele toestand te hebben bereikt, en we zien de voordelen hiervan.

Dat is duidelijk te zien aan de bovenstaande lijst. We hebben nu een Fast Builds roadmap en meerdere projectdoelen die gerelateerd zijn aan performance. Dat is erg spannend.

Er zijn ook nieuwe ontwikkelingen op het gebied van financiering. De ene is expliciet gekoppeld aan projectdoelen, daarnaast hebben we een nieuw "Maintainers in Residence"-programma en is er een nieuw financieringsteam opgericht. Ook valt op hoeveel resultaten er zijn voortgekomen uit het feit dat Hexcat het afgelopen jaar een aantal mensen in dienst heeft genomen.

...en mij

En tot slot: 2026 is ook een spannend jaar voor mij. Na een paar jaar vanaf de zijlijn te hebben toegeken en uiteindelijk bij de perf triage te zijn aangesloten, heb ik besloten om serieuzer aan het Rust-project te werken.

Begin dit jaar werd duidelijk dat ik moet beslissen waar ik me nu op ga richten. Mijn huidige werk loopt langzaam ten einde en verandert in onderhoud, en ik begon me ook een beetje opgebrand te voelen door web-gebaseerd werk. Al een tijdje voelde ik de behoefte om terug te keren naar iets technischers en uitdagenders.

Ik overwoog een paar opties, maar kon niet kiezen. Om de term van Marie Kondo te gebruiken: niets voelde alsof het "vreugde bracht" (sparks joy). Na enkele uitputtende gebeurtenissen en een avond waarop ik me wat neerslachtig voelde, ontving ik een uitnodiging voor Rust All Hands. Dit was een aangename verrassing. Ik had me begin dit jaar aangemeld, maar ik verwachtte niet echt uitgenodigd te worden omdat ik de kans niet kende. Ik zag dit als een soort teken van het universum en boekte de reis.

De ervaring was overweldigend positief. Ik moet zeggen dat dit een van de meest spannende events was die ik in lange tijd heb bijgewoond. Het herinnerde me eraan dat er een groot deel van mijn leven is dat ik bijna nooit met iemand deel, zeker niet in het echte leven. Het is makkelijk om dat te vergeten totdat je het daadwerkelijk weer ervaart.

Natuurlijk kan ik met mijn vrienden praten over curiositeiten van de Rust-compiler, maar het is een heel ander niveau om erover te praten met mensen die er daadwerkelijk aan werken en begrijpen waar je het over hebt op een diep niveau. Het was heel fijn om mensen te ontmoeten die ik ken van hun werk en deel te nemen aan discussies over de ontwikkeling van de taal.

Kortom: het werd duidelijk dat dit het is, dit is wat ik wil doen. Ik dacht er eerder al over na, maar ik denk dat ik een sterk "spark of joy"-moment nodig had om te stoppen met twijfelen aan mijn gevoelens en mezelf te dwingen een beslissing te nemen.

Hoe krijg je een baan bij Rust?

Nu is de vraag natuurlijk hoe je dat daadwerkelijk aanpakt. Zoals je wellicht weet (en ik heb hierboven al naar gehint), is het niet bepaald eenvoudig om een baan binnen het project te vinden. Er is geen bedrijf genaamd "Rust inc." waar je een CV naartoe kunt sturen.

Het is een versnipperde en diverse ruimte van mogelijkheden waarbij iedereen op zijn eigen manier zijn weg vindt. Met de nieuwe programma's wordt het toegankelijker, maar ik verwacht nog steeds dat dit tijd kost. Deels hangt het af van connecties en vertrouwen, en die worden in de loop van de tijd opgebouwd.

Ik hoef niet te haasten, dus ik blijf werken tot ik iets heb gevonden. Ik ben overeengekomen om te werken aan het projectdoel voor de reductie van de target directory grootte, mits er genoeg financiering voor is. Ik heb me ook aangemeld voor het MiR-programma, maar ik denk niet dat dat snel beschikbaar zal zijn omdat de middelen beperkt zijn en er belangrijkere gebieden zijn die deze specifieke financiering nodig hebben.

Overigens heb ik ook GitHub Sponsors geopend, dus voel je vrij om lid te worden als je compiler-performancewerk wilt ondersteunen.

Conclusie

Er gebeurt zoveel in het project dat het een uitdaging is om het eerlijk te doen. Ik heb het gevoel dat ik een hoop interessant werk heb weggelaten, maar ik moet ergens stoppen. Ik hoop dat dit onvolledige overzicht toch interessant was.

Ik moet er ook bij zeggen dat niet alles positief is geweest. Het begin van het jaar werd overschaduwd door een aantal mensen die hun financiering verloren en verhitte discussies rondom het AI-beleid. Een paar dagen voor All Hands plaatste iemand het concept-beleid op sociale media, waarna ons kleine moderatieteam en anderen een stressvol weekend hebben doorgebracht om de schade te beperken.

Met dat in het achterhoofd heb ik het gevoel dat All Hands een keerpunt was waar iedereen kon opladen, herfocussen en de positieve energie weer mee terug kon nemen naar het project. Ik voel dat zeker, en ik hoop dat ik niet de enige ben.