Rust als programmeertaal beoordeeld: is het de moeite waard om te leren?

Vraag twee ervaren Rust-developers of het leren van Rust de moeite waard was, en je kunt volkomen tegengestelde antwoorden krijgen. De een zegt misschien dat het niets voor zijn carrière heeft gedaan; de ander noemt het misschien een van de beste technische beslissingen die hij ooit nam. Allebei kunnen ze gelijk hebben.

In die tegenstrijdigheid zit de vraag „is Rust de moeite waard om te leren” eigenlijk, en daarom heb je niets aan een algemeen ja. Rust is een gecompileerde taal waarvan de veilige subset regels voor geheugenveiligheid afdwingt tijdens het compileren, zonder dat er tijdens runtime een garbage collector nodig is.

Dus ik leg me vast op een antwoord, noem de voorwaarde waar het aan hangt en laat je zien wat die voorwaarde kost.

De korte versie

Rust is de moeite waard als je iets bouwt dat lang meegaat en waarbij het je iets waard is dat de compiler een hele klasse bugs vangt. Het is de verkeerde keuze als je deze maand een CRUD-app moet opleveren, net leert programmeren of vacatures telt. 4 van de 5, met aftrek voor wat het kost voordat het iets oplevert.

• Wat je koopt: in veilig Rust veranderen de regels voor ownership en borrowing use-after-free-, double-free-, invalid-reference- en data-race-bugs in compileerfouten in plaats van productie-incidenten. Dat is het hele verhaal, en het is een goed verhaal.
• Wat je betaalt: de compiler dwingt je geheugenbeslissingen op te schrijven die je huidige taal stilletjes neemt, en in het begin voelt dat alsof de tool moeilijk doet.
• De vraag naar duurzaamheid is beantwoord. Kernelmaintainers verklaarden het Rust-experiment afgerond op de Maintainers Summit van december 2025, en in Linux 7.0 verdween het label „experimenteel”.
• De vraag naar de hype is niet beantwoord, en dat is een andere vraag. Rust staat op #10 in de TIOBE-index van september 2026, tegen #18 een jaar eerder.
• Mijn Rust-testservice had veel meer geheugen nodig om te compileren dan om te draaien: bij het bouwen piekte hij rond 1 GB, en draaiend zat hij in rust op ongeveer 3,5 MB.
• Geschikt voor jou als je al software oplevert in een andere taal en iets bouwt waarbij een geheugenbug duur zou zijn, of als je dicht bij systeemsoftware werkt. Niet geschikt voor jou als je een deadline hebt, vanaf nul begint of op zoek bent naar de taal met de meeste vacatures.

Hoe deze review tot stand kwam: de build- en runtimecijfers hier zijn van mij. Ik installeerde Rust 1.98.1, schreef een kleine Axum-webservice en mat wat het kostte om die te compileren en wat het kostte om die te draaien. Dat draaide in een afgeschermde container, niet op dedicated hardware, en het is één project, dus zie de cijfers als een datapunt en niet als een wet. Al het andere komt uit primaire of gezaghebbende bronnen: de kernelpatch en de verslaggeving van LWN daarover, de Android-beveiligingsposts van Google, de index van TIOBE zelf (met het commentaar van april via het verslag van Slashdot), Phoronix over het merge window van Linux 7.0, de CVE-registraties van de Linux-kernel voor de Binder-kwetsbaarheid, de eigen verklaring van Canonical en de enquête van Stack Overflow uit 2025. Ik heb de kernelpatch gelezen. Ik heb de Rust-code in de kernel niet geaudit. En ik schrijf nog geen jaren Rust, dus waar deze review de taal zelf beoordeelt, leunt hij op mensen uit de praktijk die dat wel doen, en noemt hij ze bij naam.

Wat de compiler je oplevert

Geef in Rust twee threads een muteerbare referentie naar dezelfde vector en de code compileert niet. Geen waarschuwing. Geen lint die je onder tijdsdruk kunt uitzetten. Het bouwt gewoon niet. Die weigering is wat je koopt in veilig Rust: use-after-free-, double-free-, invalid-reference- en data-race-bugs worden compileerfouten in plaats van productie-incidenten. De nooduitgang van Rust (unsafe) kan sommige van die garanties omzeilen, dus dit is geen absolute belofte over elke Rust-codebase.

Ownership betekent dat elke waarde precies één eigenaar heeft die verantwoordelijk is voor het vrijgeven ervan. Borrowing betekent dat je referenties kunt uitlenen, maar de compiler houdt hun levensduur bij en laat niet toe dat er een langer leeft dan datgene waar hij naar wijst, of dat een muteerbare borrow naast welke andere dan ook bestaat. In veilig Rust worden use-after-free-, double-free-, invalid-reference- en data-race-bugs door het ownership- en typesysteem gevangen voordat het programma draait.

Er is geen garbage collector, en dat is de andere helft van de deal. Omdat ownership al zegt wie wat wanneer vrijgeeft, hoeft niets tijdens runtime je heap na te lopen. Je levert een binary op zonder collector erin, en je krijgt geen pauzetijden waar je omheen moet tunen.

De prijs zit op dezelfde plek als de garantie. Elke geheugenbeslissing die je huidige taal stilletjes voor je neemt, vraagt Rust je op te schrijven: wie is hiervan eigenaar, hoe lang leeft die referentie, kan iets anders hem zien en gaat hij over een threadgrens heen. De compiler doet niet moeilijk. Hij weigert te gokken.

Dus: dit is de reden dat iemand betaalt wat Rust vraagt, en volgens mij houdt die stand. Als de klasse bugs die het wegneemt geen klasse is waar jij je zorgen over maakt, verandert de rest van deze review waarschijnlijk niets aan je mening.

Is Rust nog experimenteel, of is het inmiddels productie-infrastructuur?

Het is sinds december 2025 niet meer experimenteel, en het waren de kernelmaintainers zelf die er een einde aan maakten. Op de Maintainers Summit van 2025 concludeerden ze dat Rust zich in de kernel had bewezen, technisch en sociaal. Jonathan Corbet van LWN meldde de consensus op 10 december 2025: Rust in de kernel is niet langer experimenteel.

Rust kwam in 2022 met v6.1 in mainline Linux, juist om dat experiment uit te voeren. De patch van Miguel Ojeda die het label verwijderde, volgde drie dagen na de Summit en ging mee in het merge window van Linux 7.0.

„Maar het experiment is klaar, oftewel: Rust blijft.”

Miguel Ojeda, „rust: conclude the Rust experiment”, LKML, 13 december 2025

Los daarvan, en eerder: de Rust-herschrijving door Google van de Binder-driver van Android, de IPC-laag waarlangs de processen van Android (voortdurend) met elkaar praten, belandde in Linux 6.18, dat op 30 november 2025 uitkwam. Houd die mijlpaal los van de consensus op de Summit. Dit is het moment waarop een bedrijf een product dat echt wordt geleverd op kernel-Rust inzette, niet een groep maintainers die het idee zegende. Kernel-Rust heeft inmiddels zijn eerste CVE opgeleverd: CVE-2025-68260, een race condition in diezelfde Binder-driver die Greg Kroah-Hartman op 16 december 2025 bekendmaakte, geïntroduceerd in 6.18 en opgelost in 6.18.1. De eerste berichten gingen over crashes, maar de latere score van het CVE-team van de Linux-kernel geeft CVE-2025-68260 een 7,8 (High) en beschrijft een lokaal pad naar privilege-escalatie via geheugencorruptie in de kernel. Dezelfde driver (rust_binder) heeft sindsdien nog meer CVE's verzameld.

Bij Android wordt het bewijs cijfermatig. Het beveiligingsblog van Google meldde in december 2022 dat er nul geheugenveiligheidskwetsbaarheden waren ontdekt in de Rust-code van Android, bij ongeveer 1,5 miljoen regels Rust in AOSP en zo'n 21% van alle nieuwe native code in Android 13. Dat is een uitspraak uit 2022 met een reikwijdte uit 2022. De latere posts van Google laten de langere trend zien: geheugenveiligheidsproblemen waren goed voor 76% van de Android-kwetsbaarheden in 2019 en 24% in 2024, waarbij het absolute aantal van ruim 220 terugliep tot een verwachte 36. Die cijfers betekenen alleen iets tegen de basislijn die ze vervingen: C en C++, geschreven door zeer goede engineers met zeer goede tooling.

Twee kleinere signalen wijzen dezelfde kant op. De Apple AGX-GPU-driver in Asahi Linux is Rust, geschreven door het Asahi Linux-project als reverse-engineeringproject en niet door Apple. De rust-coreutils-update van Canonical zegt dat Ubuntu 26.04 LTS rust-coreutils 0.8.0 levert voor de meeste tools. Drie blijven op GNU coreutils (cp, mv, rm) omdat er op 22 april 2026 nog acht TOCTOU-problemen openstonden; Canonical mikt op 26.10 voor de resterende tools.

Dit is de as die ik het hoogst zou scoren, en de reden is het soort toewijding. Kernelmaintainers draaien afgeronde experimenten niet terug, Google maakt een herschrijving van die omvang niet ongedaan, en Canonical stopt geen herschreven coreutils in een LTS om eens te kijken hoe dat gaat. Wat er ook gebeurt met de populariteit van Rust, iemand moet die code jarenlang onderhouden.

Is Rust dood, of vlakt het alleen af?

Nee. Rust evenaarde in januari 2026 zijn beste TIOBE-positie ooit, #13. Drie maanden later was het teruggezakt naar #16, en TIOBE-CEO Paul Jansen schreef in april 2026, in commentaar dat Slashdot destijds citeerde, dat de groei in populariteit van Rust „lijkt af te vlakken” en dat een top-10-positie „nu verder weg lijkt dan eerder”.

Hij beschreef hoe Rust zijn hoogste positie ooit bereikte op zijn eigen index, een plek die het voor het eerst in juli 2024 had bezet, en die vervolgens weer inleverde.

De TIOBE-index van september 2026 zet Rust op #10, tegen #18 een jaar eerder, en voorbij de #13 die TIOBE in januari zijn hoogste positie ooit noemde.

Mijn lezing: het plateau was echt. Het was een luchtzak, geen plafond. Dat is beter dan de versie van beide kampen, want „Rust staat stil” klopt nu niet meer en „Rust gaat alleen maar omhoog” was nooit waar.

Het voorbehoud werkt twee kanten op, en het stuk van Slashdot bracht het destijds al ter sprake: schommelen de ranglijsten misschien gewoon mee met de maand-op-maandruis in zoekmachineresultaten, precies wat de index telt? Als een daling van drie posities in een kwartaal dun bewijs was dat Rust vertraagde, dan is een klim van zes posities dun bewijs dat het wint. Zie het als weer, niet als klimaat.

Het sterkere signaal over het sentiment is de enquête van Stack Overflow, waarin Rust opnieuw de meest bewonderde programmeertaal van 2025 is, met 72%: mensen die het het afgelopen jaar gebruikten en ermee door willen gaan. Dat is de intentie om door te gaan, geen adoptie, en hier een nuttiger signaal dan kale populariteit als je wilt inschatten of je het leuk gaat vinden om bij de taal te blijven.

Het momentum is dubbelzinnig, en ik weeg het lager dan de duurzaamheid hierboven, want je investeert niet in een ranglijst.

Wat het leren van Rust je kost

De kosten komen vroeg en in één keer. Code die Python, Java of C# probleemloos zou draaien, wordt herhaaldelijk afgewezen, om redenen die willekeurig voelen tot het ownership-model klikt, en dat kun je niet uitstellen. Je kunt niet om de borrow checker heen shippen zoals je om het niet helemaal snappen van je ORM heen kunt shippen.

Dit is het deel dat me verraste, en het werkt precies andersom dan je zou verwachten. In de r/rust-thread „Struggling to learn Rust” herformuleert het antwoord met de meeste weerklank het probleem als onbekendheid, niet als moeilijkheid, en de thread wijst ervaren developers die van talen met garbage collection komen aan als degenen die het zwaarder hebben. u/Voxelman zegt het zonder omwegen: „Rust is niet moeilijk. Het is anders.” In dezelfde thread beschrijft diegene de eigen route erheen: C64 Basic, daarna een reeks imperatieve talen, en een eerste kennismaking met Rust die „alles behalve WOW” was, omdat het afleren van oude gewoontes even duurde.

Zo ziet de rekening eruit. Als je al acht jaar Python schrijft, leer je geen set regels, je geeft een set aannames op over wie er achter je opruimt. Iemand die minder weet, heeft minder af te leren.

Nog een patroon duikt herhaaldelijk op in die thread, en het maakt van een fout in de volgorde een probleem met zelfvertrouwen: mensen lopen niet vast op Rust maar op het kiezen van een webframework, omdat ze de taal proberen te leren via Axum of Actix voordat ownership is geland. Zoals u/jmartin2683 het zei, is dat „alsof je Ruby probeert te leren door Rails te leren.”

De meeste waarschuwingen over de kosten wijzen volgens mij naar het verkeerde. Reken op langdurig oefenen, niet op een weekend, en zie vroege frustratie niet als een oordeel over wat je kunt.

Rust heeft een grotere machine nodig om te bouwen dan om te draaien

Dit is de bevinding die ik niet had verwacht: het bouwen van dit Rust-project kostte ordes van grootte meer geheugen dan het draaien. Ik bouwde een kleine Axum-service (Tokio met de full featureset, serde, serde_json, tower, één JSON-route, zo'n 60 crates in de dependency tree) op rustc en cargo 1.98.1, met strip = true in het release-profiel, en bouwde hem daarna twee keer vanaf nul:

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

Beperkt tot één compileerjob (--jobs 1) lag het piekgeheugen over cargo, rustc en de linker tussen 464 MB en 527 MB, afhankelijk van welke van mijn twee meetmethodes je neemt (ik mat het op twee manieren omdat het eerste getal te netjes leek), en het duurde 113 seconden. Met standaard parallelisme op vier vCPU's verdubbelde het piekgeheugen ongeveer naar zo'n 1 GB en was de build in ongeveer 35 seconden klaar. Parallelisme is daar de variabele, niet het project. Meer jobs betekent meer rustc-processen tegelijk in het geheugen, en daarom zijn compilers een van de weinige workloads die graag elke core pakken die je ze geeft en dat minutenlang achter elkaar.

Het afgewerkte programma is gestript 1,3 MB en gebruikt in rust ongeveer 3,3 tot 3,6 MB geheugen.

Bij standaard parallelisme is dat twee- tot driehonderd keer meer geheugen om te compileren dan om te draaien; beperkt tot één job is het nog steeds ruim honderd keer zoveel. Stem een server af op wat je Rust-service in productie nodig heeft en je kunt eindigen met een machine die hem niet kan bouwen, en dat gaat niet mis met een nette foutmelding: het is de out-of-memory killer die rustc halverwege de build afschiet, of een compiler die twintig minuten in de swap staat te malen. Twee oplossingen werken. Bouw ergens met ruimte en lever de binary op, hetzelfde patroon als een aparte buildmachine aanhouden voor zwaar Docker-werk. Of bouw op de machine zelf en geef hem ruimte: voor een service van deze vorm zijn een paar gigabyte RAM en twee vCPU's comfortabel. Lukt dat niet, dan is de nooduitgang --jobs 1 (ja, het is trager; dat is de afweging).

Als de machine waarop je werkt die ruimte niet heeft, geeft onze zelfbeheerde Linux VPS je root-toegang met facturering per uur of per maand, en een plek om de build te doen en weer in te leveren als je klaar bent. Het blijft wel een server die je zelf beheert, niet een die zichzelf beheert.

Eén project, één vorm, één machine. De machine was een gedeelde, afgeschermde container, geen dedicated server, met ongeveer 2 GB beschikbaar geheugen, dus de onbegrensde piek zat dichter tegen het plafond aan dan op een grotere machine. Dit zijn geen universele constanten: als je dependency tree vier keer zo groot is of je release-profiel link-time optimization aanzet, verwacht dan andere cijfers. Grotere dependency trees, link-time optimization en code met veel generics kunnen het buildgeheugen verder opdrijven, dus zie mijn metingen niet als een universeel plafond.

Ik schaar dit onder hoe je werkt, niet onder of je de taal leert. Weet ervan voordat je ertegenaan loopt.

Wie Rust zou moeten leren

Drie situaties waarin ik je zou aanraden de tijd erin te steken: software die lang meegaat en waarin een geheugenbug duur is, werk dat dicht bij het besturingssysteem zit, en als je wilt wat het gevecht met de compiler doet met hoe je over geheugen denkt. Voor elk ervan is er een reden dat die tijd zich terugbetaalt.

Je levert al software op in een andere taal en bouwt iets dat lang meegaat, waarbij een geheugenbug duur zou zijn. Een service die in de lucht moet blijven. Een library waar andere teams van afhangen. Alles waarbij een use-after-free een incidentreview betekent en niet een stacktrace in je terminal. Dit is het geval waarvoor de hele garantie is gebouwd, en wat je vooraf betaalt, verdien je terug over de levensduur van wat je bouwt.

Je werkt dicht bij of midden in systeemsoftware. Drivers, werk aan apparaten, basissysteemtools, embedded, alles wat onder een besturingssysteem zit in plaats van erbovenop. De industrie heeft zich hier vastgelegd zoals nergens anders, en het bewijs over geheugenveiligheid is hier het sterkst.

Je wilt het neveneffect. Twee reageerders in die r/rust-thread zijn het totaal oneens over de carrièrewaarde van Rust en komen hier toch op hetzelfde uit. u/tyler_church, die zegt dat het nul impact op zijn carrière had, erkent toch „misschien subtiele invloeden op hoe ik andere programma's in andere talen schrijf”. u/SirKastic23, al twee jaar betaald om Rust te schrijven, zegt dat het de eigen programmeervaardigheden verbreedde op manieren die nooit verwacht waren. Twee mensen, geen onderzoek, maar het is de opbrengst die overeind blijft als je nooit professioneel Rust schrijft: een verandering in hoe je denkt, geen regel op je cv.

Wie Rust niet zou moeten leren

Drie situaties waarin die tijd beter elders besteed is: je hebt deze maand een deadline, je leert überhaupt nog programmeren, of je kiest een taal op basis van hoeveel vacatures hem noemen. Over die derde wordt het vaakst gevraagd.

Je hebt deze maand een deadline voor een CRUD-app of een prototype. Rust komt precies op het verkeerde tijdschema voor werk dat er vrijdag moet staan. Go is de voor de hand liggende keuze als je een gecompileerde taal wilt met snelle builds en geheugenbeheer via een garbage collector, en je de op ownership gebaseerde garanties van Rust niet nodig hebt.

Je leert überhaupt nog programmeren. Hierover zijn mensen die hun brood verdienen met Rust echt verdeeld, en de onenigheid in de r/rust-threads gaat beide kanten op. Mijn standpunt is dus dat een beginner een muntworp in handen drukken slecht advies is, welke kant de munt ook op valt. Leer eerst ergens waar het vergevingsgezinder is hoe een machine werkt, en kom dan terug om de compiler het strakker te laten trekken.

Je kiest een taal op basis van hoeveel vacatures hem noemen. Ik geef je hier geen getal, want ik kon voor Rust geen salaris- of vacaturecijfer vinden dat teruggaat op een bron die ik zou verdedigen. Wat u/crusoe in die r/rust-thread beschrijft, is een markt met minder, meer gespecialiseerde functies. Dat is één reageerder in één thread, geen arbeidsmarktdata, dus ik zou er niet van maken dat Rust-banen breed schaars zijn. Als het aantal banen voor jou de doorslag geeft, bekijk dan de huidige vacatures in je doelmarkt voordat je de taal kiest.

Veelgestelde vragen

Is Rust gratis?

Ja. De taal en de officiële projecten zijn doorgaans dubbel gelicentieerd onder de MIT-licentie en Apache License 2.0, en de toolchain installeer je gratis via rustup. Er is geen betaalde versie en geen commerciële licentie om te kopen.

Hoe lang duurt het om Rust te leren?

Als je al programmeert, is de syntax meestal het makkelijke deel. Ownership en borrowing duren langer omdat ze veranderen hoe je over geheugen denkt, en lifetimes en async Rust voegen later nog een laag toe. Ik kon geen verdedigbare universele tijdlijn vinden, dus ik zou er geen getal op plakken.

Is Rust een goede eerste programmeertaal?

Mijn antwoord is nee, maar je moet weten dat de vraag omstreden is onder ervaren mensen uit de praktijk. In de r/rust-thread „Struggling to learn Rust” zegt u/cassepipe botweg dat Rust „geen goede eerste taal” is, na erop te zijn afgeketst en via C en C++ te zijn teruggekomen, terwijl u/Voxelman het tegenovergestelde betoogt: imperatieve talen zijn een slecht beginpunt omdat ze je gewoontes aanleren die je daarna weer moet afleren. Dezelfde onenigheid loopt vier pagina's lang door op het eigen gebruikersforum van Rust. Er is geen gevestigd antwoord van de community om te melden.

Vervangt Rust C++?

Nee. Rust wordt naast C en C++ toegevoegd en gekozen voor specifieke nieuwe componenten, en dat is iets anders. In de Linux-kernel wordt Rust naast de bestaande C-codebase toegevoegd in plaats van die in zijn geheel te vervangen. Bij Android is de aanpak die Google noemt om nieuwe code in geheugenveilige talen te schrijven, in plaats van bestaande C en C++ om te zetten. Reken op een lange periode van co-existentie.

Is Rust sneller dan Go?

Ik heb dit niet gebenchmarkt, dus ik ga niet beweren dat een van de twee categorisch sneller is. Rust geeft je fijnere controle over allocatie en heeft geen garbage collector nodig; Go gebruikt een runtime met garbage collector en ruilt wat controle op laag niveau in voor eenvoudigere ontwikkeling. Welke sneller is, hangt af van de workload, de implementatie en de bottleneck, dus gebruik benchmarks die op je eigen applicatie lijken.