"Zullen we het in Rust herschrijven?" is een van de duurste vragen die een engineeringteam verkeerd kan beantwoorden, in beide richtingen. Zegt u te makkelijk ja, dan besteedt u zes maanden aan het opnieuw bouwen van functies die gebruikers al hadden. Zegt u uit gewoonte nee, dan blijft u betalen voor servers, incidenten en latency die een gerichte rewrite had weggenomen. Dit artikel geeft u een manier om op basis van feiten te beslissen, plus een checklist waarmee u uw eigen systeem kunt scoren.
Eerst: wat levert Rust eigenlijk op?
Haal de hype weg en Rust geeft u drie concrete dingen:
- Voorspelbare performance. Geen garbage collector, dus geen GC-pauzes. Gecompileerd naar native code met controle over geheugenindeling, dus CPU-intensieve code draait doorgaans op C/C++-snelheid.
- Geheugenveiligheid zonder runtime. Hele categorieën bugs (use-after-free, data races, buffer overflows) worden al bij het compileren afgewezen.
- Kleine, zuinige deployables. Eén statische binary met laag geheugengebruik, wat telt op schaal en aan de edge.
Al het andere, zoals "het is modern" of "ontwikkelaars vinden het leuk", is mooi meegenomen maar geen businesscase.
Wanneer een rewrite loont
1. U bent CPU-bound op een hot path
Laat profiling zien dat de meeste tijd in uw eigen code zit (parsen, serialisatie, prijsberekening, matching, compressie, beeld- of signaalverwerking) en niet in wachten op een database of netwerk, dan kan Rust dat pad van knelpunt in een non-issue veranderen. Typische kandidaten: marktdata-handlers, risicoberekeningen, rule engines, ETL-transformaties.
2. Uw probleem is tail latency, niet de gemiddelde latency
Runtimes met garbage collection kunnen uitstekende gemiddelden hebben en lelijke p99's. Gaat uw SLO over de traagste 1% van de requests (trading, real-time bidding, gameservers, alles wat interactief is), dan kan het wegnemen van GC-pauzes zwaarder wegen dan pure snelheid. De vaak aangehaalde overstap van Discord, die zijn "Read States"-dienst van Go naar Rust bracht, kwam precies hierdoor: periodieke latencypieken door garbage collection, die na de rewrite verdwenen.
3. Infrastructuurkosten zijn een echte kostenpost
Op kleine schaal bespaart een 3× efficiëntere dienst een paar honderd euro per maand en is een rewrite het niet waard. Op grote schaal ligt dat anders: Cloudflare meldde dat Pingora, de op Rust gebaseerde proxy die zijn NGINX-opzet verving, voor hetzelfde verkeer zo'n 70% minder CPU en 67% minder geheugen gebruikte. Is rekenkracht een van uw grootste kostenposten, reken het dan door.
4. Fouten in correctheid zijn duur
Parsers die onbetrouwbare input verwerken, financiële berekeningen, concurrente state machines: plekken waar een geheugenbug of race condition een beveiligingsincident of een verkeerde trade wordt. De Rust-compiler vangt categorieën van deze fouten af voordat ze live gaan.
5. U moet draaien waar runtimes een last zijn
Edge-apparaten, embedded systemen, WebAssembly in de browser, CLI-tools die u aan klanten levert: één kleine binary zonder te installeren runtime is een echt voordeel.
Wanneer het niet loont
- Het systeem is I/O-bound. Besteden requests 95% van hun tijd aan wachten op Postgres of een externe API, dan maakt een snellere taal de resterende 5% sneller. Repareer de queries, voeg caching toe, bundel de aanroepen.
- Het product verandert nog wekelijks. Rust beloont weten wat u bouwt. Vóór product-market fit wint iteratiesnelheid het van runtime-snelheid.
- Niemand gaat het beheren. Leert het team dat het systeem onderhoudt geen Rust, dan creëert u een eiland. Begroot training of een partner, of doe het niet.
- Het echte probleem is architectuur. Een praatgraag microservice-ontwerp, N+1-queries of een ontbrekende queue zijn in Rust net zo traag.
- Het plan is "alles herschrijven". Big-bang-rewrites van werkende systemen zijn waar projecten sneuvelen, ongeacht de taal.
De aanpak die werkt: herschrijf het hot path, niet het systeem
In de praktijk komt het beste rendement uit het vervangen van de 5–10% van de code waar de tijd zit, en de rest met rust laten:
- Profileer met productie-achtige belasting. Flame graphs, geen onderbuikgevoel. Vind waar CPU-tijd en allocaties echt naartoe gaan.
- Zet een grens om het hot path. Definieer precies de in- en uitvoer. Deze stap alleen brengt vaak al vereenvoudigingen aan het licht.
- Herschrijf dat onderdeel in Rust en roep het aan vanuit de bestaande code. Rust integreert goed met andere stacks: PyO3 voor Python, napi-rs voor Node.js, een C-ABI met P/Invoke voor C#/.NET, of een aparte service via gRPC/HTTP.
- Bewijs gelijkwaardigheid. Draai oud en nieuw naast elkaar op opgenomen productie-input en vergelijk de uitkomsten. Property-based tests helpen hierbij.
- Meet, en beslis dan over het volgende stuk. Geleidelijke vervanging (het "strangler fig"-patroon) laat u stoppen zodra de resterende winst het niet meer waard is.
Zo blijft het risico laag, hebt u binnen weken in plaats van kwartalen echte cijfers, en levert het vaak het grootste deel van het voordeel van een volledige rewrite.
De checklist
Geef elke stelling voor het systeem dat u overweegt een 0 (niet waar), 1 (deels) of 2 (duidelijk waar):
| # | Stelling | Score |
|---|---|---|
| 1 | Profiling laat zien dat we CPU-bound zijn in onze eigen code, niet aan het wachten op I/O. | |
| 2 | Tail latency (p99/p999) of latency-jitter is een zakelijk probleem. | |
| 3 | De reken- of geheugenkosten van dit onderdeel zijn aanzienlijk en groeien. | |
| 4 | Fouten in correctheid of geheugenveiligheid zijn hier kostbaar (geld, security, vertrouwen). | |
| 5 | Het gedrag van het onderdeel is goed begrepen en redelijk stabiel. | |
| 6 | We kunnen het isoleren achter een duidelijke interface. | |
| 7 | We hebben, of kunnen krijgen, mensen die Rust-code bouwen en onderhouden. | |
| 8 | We kunnen de nieuwe versie testen met echte productie-input. |
Zo leest u uw score:
- 0–6: Nu niet. Kijk eerst naar architectuur, queries en caching.
- 7–11: Doe een proof of concept met vaste tijdsduur op het allerheetste pad, en meet.
- 12–16: Een gerichte rewrite is zeer waarschijnlijk de moeite waard. Plan hem stapsgewijs.
Stellingen 1–4 zijn het waarom; 5–8 zijn het kunnen we het. Hoog op "waarom" en laag op "kunnen we het" betekent: regel eerst de randvoorwaarden (interfaces, tests, mensen) voordat u de code aanraakt.
Wat een proof of concept moet beantwoorden
Houd het op twee tot vier weken en laat het drie vragen met cijfers beantwoorden: hoeveel sneller of goedkoper is het hot path onder realistische belasting, hoe lastig was de integratie met het bestaande systeem, en wat gaat het onderhoud kosten. Zijn de antwoorden goed, dan hebt u een businesscase. Zo niet, dan hebt u een paar weken besteed in plaats van een paar kwartalen.
Wij helpen teams precies hiermee: profilen, het hot path isoleren, het Rust-onderdeel bouwen en integreren. Zie Rust-ontwikkeling, legacy-modernisering en proof of concept-ontwikkeling, of begin met een onafhankelijke build vs. buy-evaluatie.