Volgende Linux-kernel is 7.0 en ondersteunt Rust

De volgende kernelversie van Linux zal 7.0 worden. Dat heeft Linus Torvalds bekendgemaakt. De kernel zit nu op 6.19 en daarom wordt het tijd voor een volgend nummer, zo zegt Torvalds. Rust is vanaf 7.0 definitief onderdeel van de kernel en niet langer een experiment.

Torvalds zegt dat hij 'in de war raakt van die grote getallen' in de releasenotes van 6.19. "Bijna geen vingers en tenen meer over om op te tellen, dus de volgende kernel gaat 7.0 heten", aldus de naamgever van Linux.

In een patch die in de 7.0-release komt, zit de opmerking dat het 'Rust-experiment' ten einde is. Rust is een tweede programmeertaal waarvoor ondersteuning komt in de kernel, naast C. Torvalds wil dat ook graag. Het was al in december bekend dat het eraan zat te komen.

Rust for Linux is een project dat al bijna vijf jaar loopt. Het ontwikkelteam wilde zorgen voor betere geheugenbeveiliging in de Linux-kernel door het mogelijk te maken om Linux-kernelmodules in Rust te ontwikkelen. De oorspronkelijke programmeertaal, C, is gevoelig voor geheugenkwetsbaarheden.

Linux Kernel 6.11 uit 2024

Reacties (78)

[Djerro123]

Volgt de kernel geen SemVer? Het komt nu over alsof Linus geen 20 wil als minor versie en dus kiest voor een major getal ophoging, of zit hier ook echt breaking changes in/achter?

[DeRinus]

Sinds 3.0 gebruikt de kernel fingers-and-toes versioning. ofwel 20 releases per major versie nummer.

Na 3.19 -> 4.0, na 4.19 -> 5.0, na 5.19 -> 6.0, na 6.19 -> 7.0

Het is niet gebaseerd op "major features" of "breaking changes". De kernel breekt nooit(/zeldzaam?) user-land code.

[Loller1]

Niet helemaal correct, er is wel gewoon een 4.20 gweest.

[DeRinus]

Je hebt gelijk. Waarschijnlijk heeft hij toen die vinger naar NVidia meegeteld.

[djwice]

Klopt, en die vinger is inmiddels ingetrokken en dus komen we op .19

[WigaDan]

20 is een vinger?,,,,,, Teen bedoel je.

[djwice]

0..19 = 20, we hebben het over de 11e vinger...

[WigaDan]

Verdorie

[GertMenkel]

Linux doet niet echt aan semver.

Om Linus te quoten bij de 4.21-naar-5.0-nummerwijziging:

The numbering change is not indicative of anything special. If you want to have an official reason, it's that I ran out of fingers and toes to count on, so 4.21 became 5.0. There's no nice git object numerology this time (we're _about_ 6.5M objects in the git repo), and there isn't any major particular feature that made for the release numbering either. Of course, depending on your particular interests, some people might well find a feature _they_ like so much that they think it can do as a reason for incrementing the major number.

So go wild. Make up your own reason for why it's 5.0.

[djwice]

Brilliant toch?!

[bantoo]

Linux zit eigenlijk nog steeds op 2.6.x maar dat werd zo'n groot getal dat ze nu voor de lol zo nu en dan het eerste nummertje ophogen.

[VirtualGuineaPig]

In ieder geval blij dat het geen Linux Me of Linux 26 wordt.

Of wacht 2.6 ....


mmmh.

[bantoo]

Er is niet veel wat ze tegenhoud om de volgende release Linux Vista te noemen. Nou ja, zolang er geen mensen zijn die scripts hebben geschreven die er van uit gaan dat er altijd nummertjes in de naam staan :)

[bzzzt]

Scripts met versie checks zijn meestal stom. Waarom denk je dat Microsoft van Windows 8 naar 10 is gegaan?

[Aeternum]

Rust onderdeel maken van de kernel is een behoorlijke upgrade dus een volledig versienummer is dan best wel logisch denk ik?

[lenwar]

Het idee van Semantisch Versioneren (x.y.z), is:

X.y.z. Majeurversie. Deze wordt opgehoogd als de software niet meer backwards compatible is. (als je naar deze versie gaat en je doet verder niets gaan er dingen stuk. (API's veranderen, enz.)

x.Y.z Mineurversie. Er komt nieuwe functionaliteit bij, (extra opties), maar alles wat eerst werkte, blijft nu ook werken zonder aanpassing.

x.y.Z. Patchversie. Er was ongedocumenteerd gedrag (fouten dus ) die zijn opgelost.

Het 'toevoegen van Rust', betekend (zeer waarschijnlijk) niet dat andere zaken daar last van hebben, dus dat zou geen Majeurversie moeten geven.

Wat jij beschrijft is meer op 'gevoel'. Dit is een flinke update (want, laten we eerlijk zijn: Rust toevoegen is best wel noemenswaardig), maar in het geval van Semantisch Versioneren, zou dit dus geen majeurupdate zijn.

[cdwave]

Je mag nu modules in Rust schrijven. Gewoon een leuke feature, da's alles.

[Epidemias]

Linux volgt SemVer niet. De major versie word aangepast wanneer Linus daar zin in heeft.

[downtime]

Nee, het is vrij random, bij bedrijven bepaalt de marketing vaak wat het versienummer moet zijn en bij Linux bepaalt Torvalds dat.

Ik denk dat hij af en toe het major versienummer ophoogt omdat men anders kan denken dat er in die jaren niks gewijzigd is.

[RobertMe]

Ze zijn tot 2.6.39 gegaan en toen vonden ze het goed geweest.

Linux (/een kernel in het algemeen?) is té groot om netjes semver te volgen. Sommige subsystemen zitten wellicht elke keer grote wijzigingen, incl breaking changes, in, terwijl andere subsystems vrijwel nooit breaking changes hebben. Als je echt heel strikt semver wilt volgen en als onderdeel daarvan dus breaking changes wilt verzamelen dan denk ik dat dat de ontwikkeling helemaal niet ten goede komt. Nu zijn het dus random major version bumps. Zouden ze dat niet doen zaten ze nu op 2.6.1xx. Simpelweg omdat elke release groter of kleinet is maar niks "enorm" is om een nieuwe major te verantwoorden.

En hetzelfde effect zie je bv bij browsers. Die zijn gewoon helemaal van minor versienummers afgestapt. Elke release is een nieuwe major en die krijgt een aantal patch releases. Of er in een nieuwe versie (/major) vervolgens grote wijzigingen of breaking changes zitten is irrelevant.

[doltishDuke]

Naar mijn weten zit er geen enkele logica in en is de upgrade van 6.19 qua betekenis vergelijkbaar met van 4.6 naar 4.7 of 9.12 naar 9.13.

[latka]

Semver is toch al niet meer van deze tijd: je wil feature-detection en zeker met iets grootst als de kernel (en de vele opties die er zijn bij het compileren) is het belangrijker via te bepalen of een bepaalde feature in smaak xyz aanwezig is en die dan gebruiken.

[Clemens123]

Linux breekt ook APIs in elke versie in kernel space...en normaal nauwelijks of nooit APIs naar user space. Dus welke semantiek wil je aan de versies hangen?

[Powerblast]

Nice! Toch weer een grote mijlpaal voor Rust als taal. Voor Rust vraag ik me persoonlijk nog af of de voordelen op termijn ook doorwegen in een heel groot project met veel bewegende onderdelen die continue wijzigen en refactors nodig hebben. Dat een dergelijk groot project als Linux het opneemt, geeft toch wel wat vertrouwen dat het wel degelijk de extra inspanning waard is .
Refactoren en low coupling(lees niet heel je setup moeten wijzigen omdat je ergens een mutability wijzigt) blijft toch een dingetje met Rust.

[NitSuA]

Dan ben ik toch benieuwd, als geheugenkwetsbaarheden zo’n belangrijke reden voor de overstap naar Rust zijn (ongetwijfeld zijn er meer voordelen), kan dat dan niet afgevangen worden door hele goede codescans op de huidige C code, op deze kwetsbaarheden? (Zeker nu AI steeds volwassener en beter wordt). Dat bespaart een hoop herschrijven.

[Reactie gewijzigd door NitSuA op 9 februari 2026 16:04]

[djexplo]

Het zou van uit mijn perspectief logischer zijn om alle c-code in de code geautomatiseerd naar Rust om te zetten.
Wat Microsoft ook wil doen: nieuws: Microsoft wil in 2030 C/C++ in Windows en andere code geheel vervangen door Rust

Dat kan al b.v. met C2Rust maar die maakt er onveilige Rust code van, https://c2rust.com/ .

Maar volgens b.v. Darpa kan het alleen met behulp van LLM's. Wat weining vertrouwen geeft aan onderhoudbare code.
https://www.darpa.mil/research/programs/translating-all-c-to-rust

Ook zit je met het probleem dat de meeste "die-hard" developers bij Linux waarschijnlijk van de c-school zijn, en wel c en c++ kunnen schrijven maar geen Rust .

[Powerblast]

Dat verhaal omtrent alle code van Windows herschrijven bleek volgens mij niet waar te zijn. Heb het toen even gevolgd maar geen idee wat ze er dan mee bedoelden. Alles herschrijven lijkt mij op zich ook niet zo nutttig. Moet eerlijk bekennen dat Rust ook niet alleen maar voordelen heeft. Snel itereren is er niet bij. De compiler werkt dan volledig tegen je. Dus het geeft nogal wat tegengas als je snel wat wil proberen en je design of feature nog niet 100% duidelijk is. Vandaar dat ik ook nog twijfel om er wel of niet meer mee te doen.

[Killemov]

Het zou juist een trainingsproces voor AI kunnen zijn.

[vanaalten]

Maar code moet wel onderhoudbaar blijven, lijkt mij.

Ik heb geen ervaring met C/C++/Rust of programmeren algemeen, maar is zo'n automatisch omgezet stuk code nog wel leesbaar als daarna iemand de Rust-versie wil bijwerken? Wordt eventueel commentaar in de code ook automatisch correct omgezet?

[Killemov]

Ha crust!

[bzzzt]

kan dat dan niet afgevangen worden door hele goede codescans op de huidige C code, op deze kwetsbaarheden?
(Zeker nu AI steeds volwassener en beter wordt). Dat bespaart een hoop herschrijven.

Hoewel je met code scans veel problemen kan vinden (zeker met de betere AI tools) blijft het patroonherkenning die nooit helemaal volledig is. Het grote voordeel van programmeertalen met sterke typering en geheugenveiligheid is dat je 100% zeker kan zijn dat er, als de compiler het accepteert, geen typering of geheugenbugs in de code zitten. (en ja, ik ken de 'unsafe' trucs, maar dat is intentioneel en dus ook duidelijk af te lezen aan de code)

[NitSuA]

Dank je, ik snap wat je zegt. Maar het wordt dan wel een beslissing op basis van een businesscase. Want C code inclusief goede (AI) code scanning verkleint het verschil met Rust. Dus weegt de investering dan nog op? Zeker ook het re-skillen van bestaande C devs, die mogelijk heel veel kernel / applicatie ervaring hebben en mogelijk vertrekken? Daarnaast.. hoewel Rust nu een technisch betere keuze lijkt, zal ook Rust op den duur ingehaald worden door een nieuwe taal.

[bzzzt]

Dank je, ik snap wat je zegt. Maar het wordt dan wel een beslissing op basis van een businesscase. Want C code inclusief goede (AI) code scanning verkleint het verschil met Rust. Dus weegt de investering dan nog op?

Wat kost zo'n AI scan per keer? Zeker als je bedenkt dat je die heel regelmatig moet doen kan dat best oplopen. En dan is het nog steeds niet exact dus je krijgt ook te maken met false positives e.d.
Een compiler die controleert is deterministisch dus als de code een keer goed is heb je er geen werk meer aan.

Zeker ook het re-skillen van bestaande C devs, die mogelijk heel veel kernel / applicatie ervaring hebben en mogelijk vertrekken?

Er wordt nu al meer dan 50 jaar geprobeerd veilige C code te schrijven en tot dusver is het resultaat magertjes. Als iemand dreigt op te stappen omdat die niet mee wil met een push voor veiliger code is dat misschien zelfs beter.

Daarnaast.. hoewel Rust nu een technisch betere keuze lijkt, zal ook Rust op den duur ingehaald worden door een nieuwe taal.

Hoe lang wil je daar op wachten? Rust is behoorlijk volwassen en nu beschikbaar.

[Guru Evi]

In principe wel, je kunt dus alle veiligheidsfeatures aanzetten in C compilers (stack canary etc) en bijna identieke veiligheden verkrijgen, echter, net als Rust, wordt de code dan ontzettend traag en krijg je fouten en waarschuwingen zodat ze niet volledig compileren.

Om "alle" problemen op te lossen, krijg je, net als Rust, heel veel werk (iemand moet al de aangemerkte problemen oplossen) wat in de meeste omstandigheden onnodig blijkt omdat er geen exploit path is, compatibiliteitsproblemen met andere architecturen die bijvoorbeeld, zoals Intel en moderne ARM, geen features zoals NX hebben.

Daarnaast zit er nog genoeg unsafe in Rust core libraries om enkele jaren zoet gehouden te worden, om nog niet te spreken over het libc alternatief en ook de verschillende licentieproblemen dat Rust met zich meebrengt (Rust en Rust tools zijn niet GPL en hebben ook gebruiksrestricties).

Er is een reden dat Rust nog steeds niet (goed) werkt buiten Intel en een kernel refactor is gekkenwerk. Er zijn maar een paar dingen die in de kernel zitten die Rust 'nodig' hebben en je kunt die in het algemeen eruit laten, behalve als je misschien Linux op een Apple hardware wilt draaien.

Een kernel schrijven in Rust is mogelijk (https://www.redox-os.org/) maar na 10+ jaar is het nog steeds relatief onveilig. Sommige functies zijn veilig geïmplementeerd. Andere gebruiken veilige Rust-constructies, zoals slices, maar op een onveilige manier. Weer andere gebruiken direct onveilige constructies zoals raw pointers.

[xorpd]

Ontzettend traag is ontzettend overdreven. Stack canary is een enkele compare aan het eind van een functie die objecten of arrays op de stack aanmaakt. No-execute gebeurt in hardware. Control flow enforcement technology is ook vrijwel gratis, afgezien van een extra instructie aan het begin van een functie.

NX is trouwens een afterthought, Intel had in haar oorspronkelijke implementatie van paging geen execute flag. Read access is execute access.

[Guru Evi]

Hangt af van hoeveel objecten dat je aanmaakt. Een NIC kan er wel een paar miljoen per seconde aanmaken. Een paar miljoen extra instructies kosten veel tijd, vooral op minder krachtige hardware. Daarnaast zeg ik ook dat niet alle architecturen die instructies hebben, zelfs als Intel het “gratis” doet in silicon, ARM doet het enkel op de duurdere producten en oudere chips al helemaal niet, en moet dus geïmplementeerd worden in software, wat duur uitkomt.

Daarmee dat Rust geen ondersteuning heeft buiten Intel64 en ARM64. Ook buiten Linux is Rust ondersteuning belabberd, Windows is incompleet en voor (Net)BSD kan het niet eens zichzelf compileren van source.

[punishedbrains]

Ik ben net begonnen met Rust aanleren, maar lees overal dat refactoring echt "the way to go" is. Zelf ben ik, o.a. met Java, meer van het opzetten van een goede architectuur eerst en dan pas echt doorpakken. Uiteraard rfactor je daar ook, maar werk je al volgens een bepaald principe, terwijl ik met Rust (als ik het lees dus) meer gewoon wat moet laten werken, dan directories gaan verzinnen die handig zijn. Maar kan zijn dat dat slecht advies is natuurlijk, ik moet nog beginnen aan het "Idiomatic Rust" boek.

Verder ben ik ver verwijdert van alle kritiek op Rust, dat het een meme-taal zou zijn etc. Ik snap daar werkelijk niks van, het is een taal zoals anderen, gewoon leren en wat nuttigs doen. Maar ik ben dan ook van een oude stempel I guess. :)

[Reactie gewijzigd door punishedbrains op 9 februari 2026 15:51]

[Killemov]

Schijnbaar zijn zelfs kernel developers faalbaar. Rust lijkt de remedie te zijn tegen memory-leak achtige problemen en dat is natuurlijk maar een deel van wat er allemaal fout zou kunnen gaan. Welke taal beschermt bijvoorbeeld tegen infinite loops of infinite recursions of iets vergelijkbaars?

[latka]

Infinite recursion is niet zo moeilijk: dat leid vanzelf tot een kernel-oops omdat je uit het geheugen loopt De grootste problemen (en die lost Rust ook niet op) zitten eerder bij concurrency. Dat was laatst met een CVE ook zichtbaar: het betrof rust code, maar het werd veroorzaakt door een concurrency probleem.

[wooha]

Rust Fearless Concurrency beschrijft hoe Rust wel kan helpen om concurrency veiliger te maken. Bijvoorbeeld door het gebruik van datatypes die geen uitwisseling tussen threads toestaan, waarbij de compiler kan bewijzen dat die uitwisseling niet per ongeluk plaatsvindt. Wederom met uitzondering van "unsafe" code.

Ik vraag me wel af in hoeverre dit toepasbaar is in een bestaande kernel waarin Rust met C samen moet werken en die bovendien sterk geoptimaliseerd moet blijven.

A Deep Dive into the First CVE After Rust Entered the Linux Kernel beschrijft waarom "unsafe" blocks als in de betreffende CVE soms noodzakelijk zijn, vooral in low-level code, en dat de compiler daarin lokaal code toestaat die niet bewijsbaar veilig gebruikmaakt van geheugen. Als de ontwikkelaar in die code bepaalde invarianten niet zelf correct handhaaft, dan kan het aanroepen van die code de geheugenveiligheid ondermijnen in het hele proces.

[Reactie gewijzigd door wooha op 10 februari 2026 02:14]

[latka]

Concurrency zonder shared data is eenvoudig. Niet alleen in rust.

[wooha]

Klopt. Een verschil is dat de Rust compiler voorkomt dat je in reguliere (“safe”) code per ongeluk data deelt die expliciet niet bedoeld zijn om kort of langdurig simultaan te delen. Door het typesysteem en het mechanisme van borrowing.

Rust lost problemen met concurrency niet volledig op, maar er is wel degelijk verschil met de aanpak van andere talen.

[Reactie gewijzigd door wooha op 10 februari 2026 12:31]

[Guru Evi]

Maar waarom zou je dan multithreaden? Klinkt alsof je dan beter forked. Kan Rust bewijzen dat multithreaded data “safe” is zonder de C constructies die multithreading in C veilig maken.

Er is bijna altijd bewust gekozen voor het minder veilig gedrag. Meestal zit de denkfout in “wie zal dat ooit exploiten” of de originele implementatie was goed maar wijzigingen laten variabelen en dus data reizen of langer leven naar andere delen van de code die onverwacht en onvermijdelijk zijn, gelijk welke taal dat je kiest.

[wooha]

Multithreaden of in dit geval van een kernel een gedeelde memory space kan toch handig zijn als de threads een deel van hun data wel onderling uit moeten wisselen of er gesynchroniseerd beide toegang toe moeten hebben. De kernelontwikkelaars hebben volgens mij in ieder geval gekozen voor één kernel memory space plus een heleboel al dan niet gedeelde user spaces.

Rust kan safety bewijzen voor algemene code uitgaande van de door developers beweerde safety van “unsafe” blokken code. Als een ontwikkelaar nergens “unsafe” gebruikt dan dwingt de compiler dus veilige code af, volgens een strikte en nuttige definitie van safety. Ook als diegene zelf even niet op zit te letten of verkeerd begrijpt hoe je iets hoort te gebruiken.

En ja, “unsafe” code is noodzakelijk net als in C, maar niet de default. Als je er te pas en te onpas voor kiest om het te gebruiken, dan is dat jouw verantwoordelijkheid en heb je hopelijk iets uit te leggen aan je team.

[Guru Evi]

Bewijzen is een zwaar woord. Het kan bepaalde dingen opvangen, maar je kunt dat in C evengoed doen met betere compile vlaggen. De vraag was echter om gedeelde variabelen en geheugen veilig te maken en dat kan Rust “ook” niet en daar zit nu eenmaal het probleem - gedeeld geheugen is noodzakelijk voor o.a. hardware waar een stuk hardware (NIC of RAID controller) zijn eigen CPU/geheugen heeft of processen die pakketten data behandelen, is dus relatief onmogelijk om Rust veilig te maken “compile-time” in de kernel. Je kan type veiligheid ook afdwingen met andere talen, dus waarom zit er geen Java in de kernel?

[Reactie gewijzigd door Guru Evi op 10 februari 2026 18:56]

[wooha]

Bewijzen volgens een strikte en nuttige definitie van safety en bovendien alleen in de default mode die gevaarlijk gedrag gewoon niet toestaat. Dat is volgens mij wat ik schreef. Geen magie die iets probeert te bewijzen wat wiskundig onmogelijk is.

De bedoeling is dus dat ontwikkelaars met relevante kennis in “unsafe” mode veilige primitieven ontwikkelen voor andere ontwikkelaars, zoals ze in C ook in het ideale geval zouden doen, hoewel Rust zelfs in unsafe mode niet alles toestaat wat in C mag.

Welke C compiler flags geven dezelfde lifetime en aliasing garanties en alternatieven voor unions als de Rust compiler in safe mode? Of wat is het alternatief voor dat geheugenmodel? Wat ga je allemaal achter warnings in de compiler of andere tools stoppen en wat mag er overblijven van het vertrouwde C?

Rust richt zich net als C en in tegenstelling tot Java op toepassingen met de hoogste eisen aan performance en low-level functionaliteit die bepaalde systemen vereisen. Leuk dat Java bepaalde geheugengaranties biedt, maar dat deden Python, Perl, Lisp en GW-Basic ook al met weer andere afwegingen en toepassingen.

[punishedbrains]

Ja inderdaad en daar zal wel de afkeer vandaan komen, dat Rust zogenaamd alles zou oplossen. Maar waar dat vandaan komt heb ik ook niet echt mee gekregen. Logische problemen zijn inherent aan programmeren, het enige dat Rust vrij goed doet is gewoon vaak keihard op de rem trappen.

[downtime]

Dat is gewoon een stroman die Rust-haters bedacht hebben. Niemand die ertoe doet heeft ooit gezegd dat Rust bugvrije software zou opleveren. Maar het is makkelijker discussieren als je een ander woorden in de mond legt.

[Powerblast]

Dat is inderdaad een fabeltje. Rust beschermt niet tegen functionele fouten. Het vangt vooral technische fouten op, of voorkomt ze.
Mijn grootste favoriet is bijvoorbeeld dat match (cases) elke mogelijkheid moet bevatten. Even snel één branch testen gaat dus niet, je moet ze allemaal uitschrijven. Veel gedoe als je even snel wat wil testen. Minder gedoe in de toekomst omdat je dit niet kunt vergeten. En zo zijn er nog wel wat voorbeelden . Soms denk ik echt, jongens wat een miserie, ik had beter bij Java gebleven. Om dan 5 minuten later weer verbaasd te zijn over wat de compiler catched, wat ik zelf niet had gezien.

[cdwave]

Mijn grootste favoriet is bijvoorbeeld dat match (cases) elke mogelijkheid moet bevatten.

Dat checkt the C/C++ compiler desgewenst ook.

[wooha]

(Eindeloze) recursie op stacks en out of memory situaties vanwege memory leaks zou een (Rust) compiler in het algemeen niet kunnen bewijzen. Maar een panic/crash als gevolg daarvan betekent ook niet dat het geheugen dat wel beschikbaar was onveilig gebruikt werd. Dat laatste is wat de Rust compiler bewijsbaar moet voorkomen in niet-"unsafe" code.

Maar misschien gebruik je de term wat onzuiver en bedoel je met memory-leak het onbedoeld uitlekken van gegevens vanwege onveilig gebruik van geheugen, zoals in Heartbleed. In tegenstelling tot het weglekken van beschikbaar geheugen doordat het niet wordt vrijgegeven, terwijl de inhoud niet meer gebruikt zal gaan worden. Denk bij dit laatste bijvoorbeeld aan datastructuren die onderling naar elkaar verwijzen. Rust heeft geen garbage collector om die op te ruimen. Eventueel wel weak references.

[Reactie gewijzigd door wooha op 10 februari 2026 02:11]

[mekkieboek]

Qua leesbaarheid vind ik Rust soms ingewikkeld op het eerste oog. Voorbeeld (geplukt van het web, ik ben zelf geen rust developer)

(eval $e:expr, $(eval $es:expr),+) => {{
calculate! { eval $e }
calculate! { $(eval $es),+ }
}};

Wat doet die ,+ en waarom dubbele accolade?
Ja, ook met C kun je lastig leesbare constructies maken, a = (b * **c++) << (d==2) ? 1 : 2;
Zie ook de obfuscated C contest: https://www.ioccc.org/

Maar goed, ook met Rust zal het voor een developer vast wennen in het gebruik maar ik vind (smaken verschillen) het niet perse een mooie programmeertaal.

[rjberg]

Dit is macro code, aannemende dat het echt Rust is, dat telt naar mijn mening niet echt als deel van de taal. Het is in ieder geval niet waarmee je begint, en is meer bedoeld voor speciale gevallen als het bouwen van een parser zodat je met minder code een specifiek doel kan bereiken.

[Powerblast]

Het maakt ook uit met welke taal je het vergelijkt. Als je het vergelijkt met iets zoals Python of zelfs Java of C# ziet het er erg complex uit. Als je het vergelijkt met C++ in de iets complexere gevallen is het juist eenvoudiger vind ik. Een voorbeeld: Ik zie bij Rust of een functie verwacht dat ik geheugen opkuis of niet. Bij C++ mag je gokken en hopen dat het in de docs staat. Dat maakt de syntax iets complexer maar het helpt wel heel wat issues te vermijden .

[Oudecomputer]

Rust brengt ook gigantische limitaties.
Rust is geen stabiele taal/ standaard het is nog influx wat nu in deze versie werkt hoeft niet te werken in een volgende versie. Dit ze je over een aantal jaren. Versie 1.0 vs nu kun je niet compilen. De compilers is wat op aan te merken. Linus heeft dat al gedaan.
En twee rust is niet compatibel met alles. Heel veel oude hardware is niet compatibel met rust. Dus dat moet achter gelaten worden.

[Powerblast]

Rust brengt ook gigantische limitaties.

Klopt. Het voelt soms echt aan als vechten. Iets kan wel in je hoofd of op papier werken, maar als de compiler het niet kan garanderen dat het veilig is, compileert het niet. Vandaar dat ik ook nog niet all in durf te gaan. Voor business software lijkt mij dat er steeds plaats zal zijn voor talen zoals Java en C#. Eigenlijk veel simpeler in gebruik en 95% van de tijd snel genoeg. Voor die 5% extra snelheid, geef je heel wat vrijheid op, plus ook development speed op zich. Rust schrijven gaat in mijn ervaring een pak trager dan Java. Ik moet wel zeggen, ik ben verre van een specialist in Rust, dus misschien komt dat met ervaring . Nu een jaar of 5j on and off mee bezig.

[Oudecomputer]

Niet alle platformen hebben een rust compiler. En ook het schijnt dat de compilers erg moeilijk maken om terug te lezen wat er veranderd is . Dat het dingen uit elkaar trekt. Linus had daar best wel woorden over. Een Linux kernel is altijd in development. En de rust compilers maakte het vrij moeilijk om te zien wat er nu veranderd was omdat het veel dingen uit elkaar trok . Misschien is het verstandiger om nog een paar jaar te wachten. Je ziet distributie als Ubuntu onveilige of slechte rust code pushen in de core utilities want het moet. Terwijl functies niet werken of niet af zijn of gigantische bugs hebben dat er een hotfix moet worden gepusht. Liever betrouwbare code dan halfbakken onzin met een achter deur pushen.

[jj71]

Rust is niet meer helemaal een gloednieuwe en experimentele taal en wordt al voor hele serieuze dingen gebruikt, bijvoorbeeld Microsoft wil C/C++ helemaal vervangen door Rust.

[PolarBear]

Alleen dat bericht klopt van geen kanten.

[cdwave]

De kernel houdt zich vooral bezig met het koppelen van hard- en software. Dat is een terrein waar pointers, concurrency en interrupts de hoofdrol spelen. Memory leaks zijn daar de minste van je problemen. Die komen in de kernel ook niet voor, alle geheugenbeheer wordt netjes gemanaged tegenwoordig, het is echt heel moeilijk om 't fout te doen.

Je mag nu kernel modules in Rust schrijven. Verder brengt dit geen wijzigingen met zich mee, en de kernel wordt ook niet ineens heel anders.

[xorpd]

Geheugenbeheer is ook helemaal niet moeilijk: Degene die het object aanmaakt, is verantwoordelijk voor het weer verwijderen ervan.

[cdwave]

Famous last words.

[xorpd]

Je weet niet waarover je het hebt, als je dit paradigma volgt krijg je nooit meer memory leaks. Simpel voorbeeld:

C: void mp_add(struct BIGNUM *dst, const struct BIGNUM *u, const struct BIGNUM *v);

C++: BigNum &mp_add(const BigNum &u, const BigNum &v);

In voorbeeld 1 wordt de dst pointer aangeleverd aan de procedure. In voorbeeld 2 wordt de pointer aangemaakt in de procedure. Mag jij raden wie van de twee een garbage collector nodig heeft.

[Reactie gewijzigd door xorpd op 11 februari 2026 21:22]

[cdwave]

De tweede ziet er "stuk" uit, die moet gewoon een object returnen en geen reference. De compiler maakt er dan overigens dezelfde code van als voorbeeld 1.

[xorpd]

Zou kunnen, mijn C++ is roestig. Maar je mist het punt. Het gaat om waar de allocatie gedaan wordt.

[cdwave]

In de echte wereld zijn er ook nog threads, interrupts, signals, locks, barriers en meer van dat soort interessante dingen, die het programmeren interessant maken...

[xorpd]

Ook daar geldt: je kunt het jezelf moeilijk of makkelijk maken, afhankelijk van het paradigma wat je volgt. Als je threads direct objecten laat delen dan wordt het geheugenbeheer een nachtmerrie. Daarvoor gebruik je een lock-free queue in een management thread.

[florf]

AI maakt refactoren een droom met Rust als je code goed is. One shot 90% van tijd alles in mijn code base nu (lees alles na of het klopt).

[VirtualGuineaPig]

OK, dat wordt jezelf herprogrammeren: https://rust-lang.org/learn/

[NostraDavid]

in de war raakt van die grote getallen

Maar... 7.0 is 0.81 groter dan 6.19!?
Ik ben i.i.g. benieuwd hoeveel sneller er Rust code zal worden toegevoegd aan de Kernel (in welke hoek van de Kernel dan ook).

[milliondollarman111]

Goed nieuws voor PopOS dus?

[Macfuture]

Dat was precies ook mijn reactie. Pop!OS Cosmic gebruikt deels Rust als taal. Een volgende versie (april) zou Linux kernel 7.0 gebruiken. Ik neem aan dat het o.a. extra snelheidswinst oplevert voor het fantastische OS?

[rjberg]

Betwijfel het, machine code na compilatie is machine code; er zijn verschillen, maar de interfaces van libraries zijn door het OS bepaald en de CPU architectuur, niet de taal.

Zowel Rust als C worden als machinecode gedraaid, geen interpreter, dus het is niet zo dat code opeens dichter bij de hardware staat.

[Lnaisd]

Rust is eigenlijk gewoon C maar dan memory-safe? Of zijn er ook andere verschillen buiten hoe de code zelf eruitziet.

[rjberg]

Er zal ongetwijfeld verschil zijn als je de machinecode/assembly onder een vergrootglas legt, maar in zowel theorie als praktijk zijn Rust en C talen die compileren naar directe machinecode. Rust werkt net als C zelfs embedded.

[milliondollarman111]

PopOS vind ik zelf fantastisch inderdaad.

[ioor]

Zo jammer dat t niet het spel RUST is wat ondersteund wordt...was even heel blij totdat ik alles las :p

[Noxious]

Ja dikke helaas, dat houd Facepunch heel bewust tegen (deels door EAC, maar vooral een bewuste keuze).

[Reactie gewijzigd door Noxious op 9 februari 2026 22:28]