Microsoft wil in 2030 C/C++ in Windows en andere code geheel vervangen door Rust

Microsoft wil Windows en andere software geschreven in de programmeertalen C en C++ vervangen door Rust. Microsoft wil dit in 2030 rond hebben en gebruikt daarvoor AI. Dit meldt topengineer Galen Hunt in een post op LinkedIn, waarin hij een senior software-engineer zoekt.

"Onze strategie is om AI én AIgoritmes te combineren", aldus Hunt. Hij geeft aan dat Microsoft alle grote codebases gaat herschrijven. Het streven van dit AI-gesteunde ontwikkelwerk is om per engineer elke maand 1 miljoen regels code te verwerken. Volgens Hunt is dit een 'voorheen onvoorstelbare taak', die Microsoft nu aanpakt met een zelfgebouwde krachtige infrastructuur voor het verwerken van softwarecode. De kern van deze AI-aangedreven infrastructuur is nu al op grote schaal in gebruik bij Microsoft, voor het beter begrijpen van code.

In zijn post op LinkedIn meldt de distinguished engineer bij Microsoft dat hij een vacature heeft in zijn team. Hij zoekt een 'IC5 principal software engineer', wat een senior rol is die op architectuurniveau werkt aan fundamentele, schaalbare zaken. De gezochte expert moet Microsoft helpen om de infrastructuur voor het verwerken van code te verbeteren, zodat daarmee de grootste softwareproducten geschreven in C en C++ zijn te vertalen naar Rust.

Rust is een relatief nieuwe programmeertaal die betere beveiliging biedt tegen met name kwetsbaarheden die via geheugenlekken zijn te misbruiken. De taal kwam in 2015 uit als resultaat van onderzoekswerk door browsermaker Mozilla. Microsoft kondigde in 2023 al aan dat het delen van de Windows-kernel zou herschrijven in Rust, meldt Microsoft-watcher Paul Thurrott nu. Die aankondiging kwam nadat technisch topman Mark Russinovich een verbod op nieuwe projecten in C en C++ instelde voor Microsofts ontwikkelaars. Nieuwe softwarecode moest voortaan geschreven worden in Rust, bepaalde de cto van Microsoft Azure.

Reacties (143)

[bantoo]

Nee, dit is bullshit. Verhaal van een toevallige Microsoft personeelslid. Zie ook andere Microsoft medewerkers op bijvoorbeeld /r/cpp die dit ontkrachten.

[Reactie gewijzigd door bantoo op 23 december 2025 12:11]

[.oisyn]

Het komt van Galen Hunt, die inmiddels ook een correctie van zijn LinkedIn post heeft geplaatst:

quote: https://www.linkedin.com/...vity:7407863239289729024/

Update:
It appears my post generated far more attention than I intended... with a lot of speculative reading between the lines.

Just to clarify... Windows is *NOT* being rewritten in Rust with AI.

My team’s project is a research project. We are building tech to make migration from language to language possible. The intent of my post was to find like-minded engineers to join us on the next stage of this multi-year endeavor—not to set a new strategy for Windows 11+ or to imply that Rust is an endpoint.

[Blokker_1999]

Dat lijkt me ook wat ik tussen de lijnen las, maar mijn god, dat had hij direct beter moeten verwoorden. Een man met zo een ervaring hoort beter te weten imho.

[punishedbrains]

Ach, dat zegt allemaal niet gek veel. Je zou dat beter kunnen aanpakken, maar in de praktijk zie ik constant blunders ondanks ervaring. Menselijk, maar ook deels niet altijd slim. Je ziet hier eerder het effect van een social medium, iedereen duikt er meteen op en dan vergroot je de normale oepsjes enorm.

[Reactie gewijzigd door punishedbrains op 24 december 2025 11:01]

[vassago]

Misschien handig als je er dan ook een bron bij geeft?

[bantoo]

Exercise in Removing All Traces Of C and C++ at Microsoft : r/cpp

Beginpunt om te lezen, onder andere de gebruiker STL (MS) heeft hier het nodige over te zeggen.

[MSalters]

En voor diegene die 'm niet bij z'n initialen kennen: Stephan T. Lavavej, Dé Microsoft engineer voor hun C++ Standard Library implementatie.

[zordaz]

Haha, inderdaad. Als iemand momenteel zo'n uitspraak doet dan weet je meteen hoe laat het is:

"Onze strategie is om AI én AIgoritmes te combineren"

Eigenlijk zou Tweakers hier ook wel wat beter op mogen filteren voordat er een nieuwsartikel van gemaakt wordt. Iets met kaf en koren enzo...

[Reactie gewijzigd door zordaz op 23 december 2025 13:13]

[bantoo]

Ik vind het ook nogal absurd dat dit niet ergens argwaan oproept voor publicatie maar goed dat is persoonlijk waarschijnlijk.

[zordaz]

Ik mis helaas toch te vaak de journalistieke waarheidsvinding. Het bekende probleem van veel online nieuwssites. Te bang om een primeurtje te missen of clicks mis te lopen.

[trucker0werner]

Vooral de laatste. Its all about the clicks.
Je naar site lokken die vol staat met reclame.
Zoveel dat je nieuwsbericht niet meer kan lezen. Het is jammer dat hiertegen niks wordt gedaan google en facebook promoten juist zulke sites. Beter pagina met 2 a 3 reclame berichten ivm de kans dan groter is dat je die ziet enof leest.
Bij 10reclames kijk ik naar geen enkel. Dus werkt het averechts

[bramv101]

Is zeker niet absurd, ik zou ook verwachten dat een tech redactie dit onmiddellijk herkent als onzin.

[Patrick1995]

Ja dit is echt zo onrealistisch. Vooral deze zin:

Het streven van dit AI-gesteunde ontwikkelwerk is om per engineer elke maand 1 miljoen regels code te verwerken.

Windows 10 werd geschat op 50 miljoen regels code. Dus dan zouden ze met 50 engineers in één maand tijd heel Windows omzetten naar Rust. En er zullen veel meer engineers aan Windows werken, dus dan kan het nog veel sneller.
Dat kan natuurlijk nooit zo snel.

[Zoijar]

Ik miste eigenlijk nog een beetje dat het op de block chain werd gecodeerd, dan hadden ze meteen alle hypes.

[StackMySwitchUp]

Blockchain is zo 2023

[goarilla]

+Quantum and cold fusion.

[Yalopa]

Waarom? Als je kijkt wat Microsoft allemaal aankondigde in het laatste jaar dan is dit gewoon “practice what you preach”

[Vaevictis_]

Lijkt me ook hele codebase refactoren met alle legacy shit erin dat gaat ze heel veel tijd kosten als ze het al getest krijgen. Levert ook heel weinig op en vraagt veel capaciteit die niet in innovatie kan worden gestoken. En waarschinlijk ook nog eens met minder ervaren mensen. Dit is een ramp in wording als het plan waar is.

[Killemov]

Ik vermoed dat AI hier een grote rol in zal gaan spelen. En dat lijkt mij ook een prima moment om legacy crap te lozen.

[andries98]

Ai is nou niet bekend om zijn efficient werkende code... ook is het altijd erg moeilijk om legacy code (en data) te verwijderen op een manier dat alles blijft werken (heb nog nooit een project soepel zien overgaan naar flink gereviseerde/geupgrade versie). Dat vraagt juist super veel handwerk om te zorgen dat het goed blijft werken met oudere data, andere programma's, efficient blijft en niet juist nog meer errors en daarmee bugs/loopholes voor misbruik creert.

Het klinkt altijd heel makkelijk, maar in de praktijk blijkt het altijd extreem lastig. Vandaar dat de huidige windows nog steeds (geupgrade) elementen van het dos tijdperk gebruikt. Ooit zal het toch een keer moeten, maar ik heb wel twijvels over de redenen en het optimisme wat er achter lijkt te zitten.

[Reactie gewijzigd door andries98 op 23 december 2025 14:52]

[Lord Anubis]

Idd, vroeg 3 verschillende AI’s om een stuk roestige rust code wat ik ooit geschreven had te auditeren, kreeg 3x keer zoveel code terug met allerlei fratsen wat totaal geen nut had en niet eens meer wilde werken.

Terzijde lijkt me dit een broodje aap verhaal dat MS dit gaat doen; misschien als proef parallel project.

[rboerdijk]

Zelfde ervaring hier, dus samen N=2

Wilde een enkele functie die iets deed met camerazoom en de edges van het frustum op een bepaalde z-waarde binnen een gebied houden (dus niet eruit laten)... Heb echt serieus mijn best gedaan via chatGPT, en het kwam redelijk in de buurt, maar toch net niet. Twee avonden mee bezig geweest.

Daarna zelf "from scratch" geschreven, klaar binnen 2 uur (toegegeven, ik had ondertussen dus 40-50 implementaties gezien dus begreep het probleem dus steeds beter) maar toch, we hebben het over 1 functie... Als ik zo'n nieuwbericht zie met de titel "alle legacy C/C++ code herschrijven via AI"... ai, ai, ai...

[Reactie gewijzigd door rboerdijk op 23 december 2025 21:22]

[blorf]

Blijf bij C. Het is allemal bytes, Niks aan te doen met compilers en zo.

[SPee]

Mijn frustratis met AI groeit ook.

Ik had een aantal functies incl commentaar wat het deed (kopie vanuit andere taal) en vroeg aan de LLM "gebruik de functienamen en commentaar en genereer daarvan de implementatie". Ik kreeg terug: de functies in correct formaat en elke functie had als inhoud "// TODO maak de implementatie voor deze functie". Dus niet alleen geen implementatie, maar ook de commentaar was ik kwijt.

Weer een paar pogingen verder kreeg ik grotendeels werkende code. Maar niet in de framework die ik wou gebruiken. Plus de database queries waren volledig Strings, dus lekker veilig tegen Johnny Tables. Dus weer een paar iteraties verder en daarna nog zelf wat correcties uit moeten voeren, maar het compileert.

Code is niet zoals taal makkelijk een op een over te zetten in een andere taal. Een programmeertaal heeft bepaalde (on)mogelijkheden en werkwijzes die je op een of andere manier moet kunnen overzetten in een taal die anders werkt. Een LLM kan je daar maar beperkt mee helpen. Er zijn teveel keuzes die je daarvoor moet maken. Zelf denk ik dat het mogelijk sneller gaat zijn als je de binary output decompiled. Die wil je immers hetzelfde houden én het bevat geen taalspecifieke dingen.

[Powerblast]

Zal inderdaad een grote rol spelen om nog een grotere mesthoop op te leveren. Mijn ervaring met AI en Rust is dat het er niks van snapt. Ik zie het niet gebeuren. Basic voorbeeldjes die ik zelf ook kan uitvinden, helemaal perfect, zolang ze goed als letterlijk uit het Rust book komen zeg maar. Vraag je wat complexer met lifetimes en dergelijke, vergeet het, het sukkelt er zelfs nog harder mee dan dat je zelf doet.

Rust moet zich op lange termijn in zeer grote codebases vind ik nog steeds bewijzen. De taal is daar mijn inziens te jong voor om nu al te kunnen inschatten of alle problemen die legacy code met C++ oplevert, volledig opgelost zijn.

Dit lijkt mij vooral weer een artikel dat gestockeerd kan worden onder wij van de AI boer moeten onze AI spullen verlappen, want de animo begint wat in te zakken. Dit lijkt een uitgelezen kans. Ik ben zelf ook voorstander van Rust, maar de algemene trend binnen de community is wel een beetje van alles moet herschreven worden in Rust of het niet is OK. Daar ben ik dan weer niet akkoord mee. Dat is voor een OS zoals Windows zelfs een heel groot risico.

Misschien dat het met talen zoals Python, Java, C# beter gaat. Maar met talen zoals C, C++, Rust... Hoe complexer de taal, hoe meer hallucinaties dat ik krijg bij prompts. API's die niet bestaan, parameters die het "plots" vergeet. Als ik dan doorvraag, zijn het plots inderdaad versies die niet bestaan en de eindconclusie is meestal: ja, je bent niet alleen met frustraties met library X. Laat ons Y gebruiken, dat lost het volledig op! Om dan gewoon hetzeflde gedoe vanaf het begin opnieuw te krijgen.

[Reactie gewijzigd door Powerblast op 23 december 2025 15:44]

[Immutable]

Mijn ervaring is juist dat door de goede Rust compiler feedback en juiste prompts rust juist perfect is voor LLM's. Heb een volledige DSP library geschreven met 1000 tests. Voor de grap. Zo'n beetje hele matlab vervanging. Rust met hele goede compiler output is juist veel beter dan compilers met output waar je niet zoveel mee kunt. En C++ is een stuk complexer en door veel training op oude slechte C++ code zou het juist met C++ slechter af moeten gaan.

[Reactie gewijzigd door Immutable op 23 december 2025 19:47]

[Powerblast]

Ik kom in ieder geval niet voorbij de gewone basic voorbeelden met een AI bot eens ik er Rust insmijt. Voor de grap een testcase met een aantal lifetimes erin gezet. Ik kwam er zelf niet uit waar ik nu wat verkeerd deed, dus dacht ik probeer het eens. Ben letterlijk een uurtje bezig geweest met rondjes draaien. Lifetime hier weg, daar erbij, nope geen compile. Stelt hij terug voor om het terug te zetten zoals het stond... weer verder, nope geen compile. Stelt hij weer voor om terug oplossing B te proberen... enzovoort. Ik bleef gewoon in rondjes draaien.

Ik verwacht op dat moment eigenlijk dat de bot me dan voorstelt om een volledig andere oplossing te proberen, wat ik uiteindelijk ook gedaan heb .

Gebruik van libraries, net hetzelfde. Ik kom meestal tot het punt dat de AI bot zegt dat ik een andere library moet gebruiken "want iedereen is gefrustreerd over het gebruik van library X". Heb het zelfs eens gehad over serde (meest gebruikte serialization lib voor Rust), ja hoor... dat hij dan gewoon zegt dat hij het ook niet weet...

Het zal denk ik ook van sector tot sector afhangen. Ik gebruik het vooral voor gamedev related stuff. Daar is de tooling toch nog niet echt wat het moet zijn. Veel libraries werken wel, maar met vreemde issues of meer C++ like API's dan echte Rust like API's waardoor je op veel plaatsen nog unsafe nodig hebt. Dat maakt het ook niet eenvoudig maar dat is een kwestie van tijd.

[Reactie gewijzigd door Powerblast op 23 december 2025 20:22]

[SPee]

Ben letterlijk een uurtje bezig geweest met rondjes draaien. Lifetime hier weg, daar erbij, nope geen compile. Stelt hij terug voor om het terug te zetten zoals het stond... weer verder, nope geen compile. Stelt hij weer voor om terug oplossing B te proberen... enzovoort. Ik bleef gewoon in rondjes draaien.

Zoiets schreef ik eerder ook

Zelfs met db interactie heb je problemen. Een query volledig in een String maken, hoezo sql injection? En query.execute(&db) verwacht toch echt een andere type parameter. En die result is een Option die je dus niet direct kan gebruiken. En de waarde uit een veld ophalen vereist een tweede parameter in row.try_get("column"). Mogelijk niet in een ander framework, maar dat onderscheid ziet een LLM niet zo makkelijk.

Leuk dat het soms goed werkt, maar als je daar buiten valt, dan begint het frustrerend te worden.

[MIB75]

"Ik vermoed dat AI hier een grote rol in zal gaan spelen."

Zou het? Lees voortaan eerst het artikel, want dit staat er letterlijk in.

[Halfscherp]

volgens onderzoek maakt AI je gemiddeld 14% trager (terwijl men zich 20% sneller voelt).

Iedereen met een beetje kennis van zaken weet allang dat qua productiviteit AI echt een wassen neus is.

Veel succes gewenst met door een miljoen regels code heen ploegen.

[Reactie gewijzigd door Halfscherp op 23 december 2025 18:50]

[Firestorm666]

Hang er vanaf.

Ik kan relatief ingewikkelde powershell scripts laten maken door ChatGPT. Zelf heb ik wel kennis van Powershell, maar absoluut geen guru hierin. Dus voor mij ben ik wel degelijk sneller met AI dan zonder.

Kan me voorstellen dat als je wel een Powershell guru bent, er vast situaties zijn waarbij je even snel of sneller een werkend script kan maken van de 1ste keer.

Problemen ontstaan wel als je totaal niet weet met wat je bezig bent, dan kan je je AI agent ook niet corrigeren. Hoe langer je gesprek wordt, hoe groter de kans dat AI zichzelf in een loop zet. Soms moet je ook gewoon zoals in de "oude" tijd zelf effekes een zoekmachine gebruiken.

[punishedbrains]

Wat mij opvalt is, als je basiskennis hebt en gewoon een gezond stukje verstand (dat is lastig aan te leren, maar soms voel je na jaren computer gebruik dingen gewoon aan) je een heel eind komt. Ik configureer nu een mooie Podman server, flink beveiligd en door antwoorden die het geeft aan te passen tussentijds (lukt met Claude goed) stuur je het een best goede kant op. Na wat heen en weer, dingen aanpassen of opnieuw doen, ben ik nu bij een setup die ik tijdens mijn eerste homelab oefening 2 jaar geleden ook had, na destijds een maandje of wat flink stoeien. Uiteraard is dat wel van belang dan, ik ben er geen expert in maar had al wel een keer alles opgezet en ken de do's en don'ts. Als ik lukraak wat probeer en niet bij stuur of doorvraag, nee dan kom je er niet echt. Deze server staat apps te draaien van begin van opzetten tot beveiligd eindpunt binnen 2 dagen.

[Reactie gewijzigd door punishedbrains op 24 december 2025 11:09]

[latka]

De enigste bestaansreden van Windows is dat het legacy crap tot in de eeuwigheid ondersteunt. Nee, de kans dat dit gedaan gaat worden is 0%: het is een ongelofelijk bedrijfsrisico, levert niets op (security? Sure. Zie recente CVE tegen Rust in de Linux kernel) en kost ongeloofelijk veel moeite (zelfs of zeker met AI omdat er allemaal bugs in Windows zitten waar software op leunt). Dit bericht had voorzien moeten worden van "hoax" of "gerucht", maar zoals het nu geschreven is is het een site voor techneuten niet waardig.

[scsirob]

De upside voor Microsoft om alles van C/C++ naar Rust over te zetten is miniem. Dat gaan ze niet doen. Microsoft is een bedrijf, het richt zich op geld verdienen. De enige reden om C/C++ om te schrijven naar Rust is als het financieel zinnig is, op korte en langere termijn.

Rust kan problemen met memory management (memory leaks, verkeerde pointers, use-after-free) vermijden. Als MS heel veel geld kwijt is aan support en patch management omdat het in de huidige codebase wemelt van dat soort fouten dan kan het zinnig zijn. Memory managementfouten uiten zich vaak door BSOD (of wat daar tegenwoordig voor doorgaat). Heel eerlijk? Die komen niet zo heel veel meer voor. Zeker in een code base van 30 jaar oud is het meeste low-level memory management inmiddels bewezen stabiel.

Wat er nu aan bugs in de Windows code zit zijn eerder logic errors. Daar gaat Rust weinig aan veranderen. Een foute afslag is een foute afslag in iedere taal.

[batteries4ever]

Maar het zou zoveel verklaren over de tonnen aan shit die MS de afgelopen 40 jaar over mijn hoofd heeft uitgestort. Soms zou ik wel Windows Updates willen stoppen omdat die tot dusverre ordes van grootte meer schade hebben aangericht dan alle virussen op de wereld bij elkaar...

[Bliksem B]

Zie ook zijn eigen rectificatie https://www.reddit.com/r/cpp/s/rrMRb3jMjq

Update:
It appears my post generated far more attention than I intended... with a lot of speculative reading between the lines.

Just to clarify... Windows is *NOT* being rewritten in Rust with AI.

[badeendjuh]

Behalve het inherente veiligheids aspect van het gebruik van Rust tov C is er nog een andere motivatie. Namelijk dat de Amerikaanse overheid aanstuurd op het gebruik van "memory safe" in software

https://stackoverflow.blog/2024/12/30/in-rust-we-trust-white-house-office-urges-memory-safety/

Dit zal op termijn ongetwijfeld een eis worden in (overheids) aanbesteding trajecten van software. Dus wil je die deals straks niet missen, moet je nu aan bak.

[Zezura]

Er bestaat niet zoiets als memory safe programmeer taal of programma. Elk programma, programmeer taal en instructieset gebruikt geheugen. Echter is de drempel om goed te programmeren in C en C++ veel hoger dan Rust op dat gebied. Wil niet zeggen dat Rust per definitie beter is dan C++. In Rust kan je ook domme fouten maken die RCE’s e.d. mogelijk maken. Geen enkele taal of hardware is 100% safe.

Erger vind ik dat het een hype is, programmeurs denken dat het door deze hype idd niet kan en minder moeite stoppen in goed en veilig programmeren, zoals je in C/C++ de drang wel degelijk voelt. Je moet snappen wat je doet als pointers, references en tekens zoals * & op een bepaalde plek zet.

[wooha]

Er bestaan memory-safe programmeertalen. Range checking, type checking en reference/reachability checking zijn volgens mij voldoende. Maar uiteindelijk rust elk programma inderdaad op stukken code of hardware die niet in een memory-safe taal zijn beschreven. Die talen voldoen niet aan de eisen voor de low-level of high-performance toepassingen waar C/C++, Rust en assembly zich op richten.

In Rust verandert de drang naar memory-safe programmeren naar dwang doordat de compiler code controleert en niet accepteert als die niet bewijsbaar memory-safe is, uitgaande van bepaalde constraints op en tussen unsafe blocks (en een foutvrije compiler). De enige manier om die controle deels (!) te vermijden is door de nieuwe code ook in een unsafe block te plaatsen.

Programmeurs die unsafe blocks gebruiken zouden minstens dezelfde drang moeten voelen als C/C++ programmeurs om zelf na te denken over die constraints als hun (gerelateerde) unsafe blocks gebruikt gaan worden vanuit "safe" code. Fouten daarin maken namelijk die memory gerelateerde RCE's e.d. mogelijk. Buiten unsafe blocks hoeven ze voor memory-safety hun code "alleen maar" door de compiler te loodsen. Dat zou ook moeten motiveren om na te denken of een unsafe block echt nodig is en de moeite en het risico waard is. Het "alleen maar" van de compiler is overigens al niet triviaal, want ook daarvoor moet je snappen wat je doet en welke minimale eisen de compiler aan "safe" code stelt.

[latka]

Die eis was er al bij kritieke Defensie zaken. Die zijn daarom vaak al in Ada geschreven.

[wiseger]

Dit artikel is geschreven in december 2024. Dit gaat dus over een wens van de Biden administratie.

Of de Trump administratie er net zo overdenkt, is maar afwachten. Er is een hoop veranderd bij de Amerikaanse overheidsdiensten in 2025.

[Powerblast]

Dat roepen ze al even maar ondertussen gebruikt NASA en dergelijke nog steeds gewoon C in grote mate om raketten naar de maan te krijgen. Blijkbaar is het daar dan wel betrouwbaar genoeg voor .

Rust gaat hier echt niet op zo een korter termijn het even volledig overnemen. Misschien tegen 2040, zou goed kunnen, maar met het tempo waarmee er momenteel industry adoption van Rust is, gaat het veel te traag om 2030 volledig over te zijn.

[Immutable]

Waarom niet? De C die daarvoor gebruikt word is niet de C die Jan en allemaal zo programmeert. Het is een zwaar gehandicapte vorm van C. Namelijk MISRA C waarin je veel dingen niet mag.

Default Rust vangt al ongeveer 80% van MISRA C regels af. En die laatste 20% kun je ook wel afvangen door speciale Rust compiler toolchain zoals die van https://ferrocene.dev/

Ik zie geen enkele reden waarom kritische zaken bij o.a. NASA en defensie niet binnenkort ook steeds meer over zullen gaan naar Rust. Geef eens een goede reden van waarom niet? Dat je bestaande code niet herschrijft snapt iedereen.. dat is flauwekul. Maar naast dat is er weinig redenen van waarom niet.

[Powerblast]

Ik zie persoonlijk ook geen reden om het niet te gebruiken, daar ben ik het volledig mee eens. Maar het is wel zo dat C programmeurs meestal niet zo happig zijn om de laatste nieuwe hypes te volgen. Die blijven liever bij wat ze al kennen en ook al jaren gewoon goed werkt. C werkt en je kan er ook zeker van zijn dat het dat binnen 50j ook nog zal doen. Van Rust is dat nog niet zo zeker.

Ik vermoed zelf ook dat het wel zal blijven, maar als je naar de adoption rate kijkt, gaat het wel erg traag. De Rust jobs groeien nog steeds niet aan de bomen, ookal is de taal ondertussen 10j in v1.0.

NASA zie ik voor flight control en dergelijke er nog niet zo snel opspringen. Die willen een taal die zich ondertussen al 50j bewezen heeft. Waarvan ze zeker zijn dat geen vreemde issues krijgt als je rond Mars vliegt .

Rust maakt bepaalde dingen terecht moeilijk, maar het is soms echt vechten vind ik met de borrow checker om iets gedaan te krijgen. Ookal weet je zelf dat je 100% juist zit qua memory, nope de compiler schiet het af want hij kan het niet checken. Dat heeft z'n voor een nadelen.

[hackerhater]

Zeker, maar ik zie ze het wel gebruiken voor spul dat niet super kritisch is.
En dan later wanneer Rust zich meer bewezen heeft het meer kritische deel.

[GertMenkel]

Ik betwijfel dat de deadline haalbaar is maar ik verwacht dat dit Windows een behoorlijk voordeel gaat geven boven de concurrerende kernels.

Ik ben benieuwd of Apple nu ook hun Mach-kernel naar Swift zal beginnen om te schrijven de komende jaren. Rust doen ze voor zover ik weet niet zo, maar met Swift is ook een hoop veiligheid te behalen die je met ouderwetse C (en voor API's Objective-C) niet eenvoudig bereikt.

Ergens vind ik het ook wel komisch danwel triest dat Microsoft hierin zover voorloopt op de open source wereld. Een open programmeertaal die zijn belangrijkste use case terugvindt in één van de weinige gesloten kernels die wereldwijd gebruikt wordt. Hopelijk wordt de situatie op Linux beter nu Rust uit de probeerperiode is, maar na de actieve sabotage en pesterijen van Linuxkernelmaintainers verwacht ik dat het nog wel even zal duren.

Dat gezegd hebbende heeft Google voor Android de Bluetoothstack en Binder ook al naar Rust omgeschreven, dus wie weet worden de grote bedrijven de drijfveer wat de Linuxkernel betreft.

[Scribe]

Voordeel? Ze gaan helemaal niks doen behalve het hele OS door een LLM gooien. Denk niet dat het nog opstart daarna

[Prince]

Een generiek LLM dat alle talen spreekt en bijna alles van alle aandachtsgebieden weet, die zal dit niet zo geweldig kunnen. Maar een AI die getraind is om C/C++/C# code om te zetten naar Rust, die zal dit vrij foutloos doen. Onthoud dat MS niet zomaar een LLM gebruiker is. Ze hebben verschillende modellen gemaakt en hebben dus al redelijk wat ervaring.
Ik kan er ook best in komen dat ze voor de meeste componenten goede unittests hebben. Deze kunnen dus direct controleren of de output dezelfde is op de verwachtte input. Pas als dit niet zo is, of de performance lager ligt, zal de developer ernaar kijken.

Een 2de stap is dan om AI voorstellen te laten maken om de code robuster te maken, oude code en andere technical debt op te lossen en misschien ook een paar performance optimalisaties door te voeren.

[latka]

"een AI die getraind is om C/C++/C# code om te zetten naar Rust" noemen we al sinds 1960 een compiler... Meestal naar machine-code dus tegenwoordig eerder een 'transpiler' maar dat is gewoon een compiler voor mensen die dat woord niet willen gebruiken.

Compilers zijn al niet foutvrij en zijn eenvoudiger qua correctheidsbewijzen dan een AI LLM model. Dus nee.
Heb al eens met automatisch omgezette code-bases mogen werken. Dat wens je je ergste vijand nog niet toe. Het is meer dan omzetten. Vaak moeten er ook paradigma's om (voor C naar Rust valt dat gelukkig wel mee, behalve zaken als de borrowchecker gelukkig maken).

[FreezeXJ]

Gewoon net zo lang tussen LLMs heen en weer laten pingpongen tot het werkt... Kost misschien een paar jaar (iets met apen en typmachines) en je houdt bakken bugs, maar het kan zeker. Kun je daarna je 'AI' trainen om bugs op te lossen ('mark as feature').

[Firestorm666]

Je ziet de resultaten nu al.. elk ding dat de nieuwe GUI krijgt is opvallend trager zonder dat er functionaliteit bij is gekomen. Dat is toch ook een kunst op zich.

Volgens mij gaan hun vergaderingen alsvolgt: we hebben product x.... zeg, dat werkt wel iets of wat tegoei.... hoe kunnen we het verkloten?

[Scriptkid]

Tja hit is een

Lost language model 😅

[bzzzt]

Vooral leuk als de LLM het nodig vindt code als 'unsafe' aan te merken...

[Sandor_Clegane]

Waar uit dat voordeel zich in?

Eerst zien dan geloven, de rest van je verhaal is: theoretisch klinkt het mooi. Ja Rust heeft was slimme dingen qua memory management, maar wil je bepaalde dingen kunnen doen dan sluipt "unsafe" er al gauw weer in.

[Reactie gewijzigd door Sandor_Clegane op 23 december 2025 14:13]

[Loller1]

Dus Tweakers, gaan jullie dit bericht nog updaten om te zeggen dat het onzin was? Zelfs de man die de post plaatste waarop dit artikel gebaseerd is, is nu naar buiten gekomen om te zeggen dat zijn post volledig gemisinterpreteerd was.

[Scribe]

Niks mis met Rust, en dit zou technisch gezien een best goed idee kunnen zijn, maar we hebben het hier over kritieke infrastructuur eigenlijk (Windows wordt nogal veel gebruikt)

Maar het echte probleem zit er natuurlijk in dat we straks heel Windows door AI geschreven hebben, en dat gaat me toch een gigantisch zooitje worden

[NoTechSupport]

MS-software is de laatste tijd in mijn ervaring veel bug-gevoeliger geworden. Zowel in Windows, Teams, Outlook als SharePoint vind ik regelmatig problemen die ik tot anderhalf jaar geleden nooit zag.

Dat gezegd zijnde is AI enorm nuttig bij het programmeren. Er moet alleen genoeg gecontroleerd en getest worden. Vermoedelijk kan dit in de toekomst ook met AI, maar in mijn ervaring zijn we daar nog niet.

[Powerblast]

Je laatste punt is inderdaad ook mijn ervaring. Ik ervaar persoonlijk momenteel geen verschil tussen de hoeveelheid werk dat ik heb met een code review van een AI bot of van een junior. Evenveel wtf momentjes zeg maar .

Voordeel met een junior developer is dat ik nog kan vragen waarom hij tot bepaalde conclusies is gekomen. AI draait bij dergelijke vragen dan wat rond de pot om me dan als oplossing een ander framework voor te stellen . Ja dat lost het probleem wel op ja...

[latka]

En een junior developer leert van zijn fouten.... de AI leert pas bij de release van een nieuwe trainingsset, ofwel: dat heb je niet in de hand. Aan de andere kant: een falende AI vervangen door een ander model stuit op minder weerstand dan een junior die er niets van bakt (en lijkt te gaan bakken) eruit gooien....

[Mizgala28]

1 van de vele redenen dat ik de AI bubbel graag permanent zie barsten.

Maar misschien is het juist tijd dat MS eindelijk z'n eigen graaf graaft, ik gebruik Windows maar wat MS de laatste jaren doet, vooral sinds W11 (probleem is er al langer dan dat, maar sinds W11 slaan ze echt door) verdienen ze dat.

Nu nog werkelijk in dat graaf liggen en begraven worden... misschien ook meteen een nieuwe CEO installeren.

[BURN3R]

Ik denk dat ze best wat kunnen besparen als MiCo de huidige CEO vervangt.

[Frappuccino]

Graaf.

[Mizgala28]

Ook zo'n ding, zet je de autocorrect uit op je telefoon en de toetsenbord past doodleuk achteraf aan wat je typt.

Extra leuk als je in het Nederlands iets wil typen en hij maakt er een engels woord van omdat je regelmatig beide gebruikt.

Geen probleem op PC gelukkig.

[R4gnax]

Ze gaan dus ook Windows à la vibe-coding carte herschrijven? Serieus?
Met alle foute code die dat uitspuugt en dan op de toon van een totaal onhaalbaar target dat het onmogelijk maakt om de correctheid van de door AI geproduceerde Rust code te verifiëren?

Met ook nog even in het achterhoofd houdende dat OS kernel code heel erg gevoelig is voor zaken zoals concurrency / multi-threading, waar zelfs menselijke engineers met enorm veel seniority blijvend moeite mee hebben? En waar LLM modellen op het moment echt compleet geen kaas van hebben gegeten?

En dan hebben we het nog niet eens gehad over alles wat niet 'the happy path' is - foutafhandeling, fuzzing van edge cases, potentiële security vulnerabilities wanneer zaken fout afgehandeld worden. Etc. etc. etc.


Nou jongens...
The year of the Linux desktop lijkt er dan wellicht eindelijk te komen, maar wel even op een andere manier dan gedacht...


Lijkt er op dat de Windows NT kernel eindelijk aan een naamsvernieuwing toe is:
Windoes n't

[Reactie gewijzigd door R4gnax op 23 december 2025 12:15]

[Mathijs Kok]

Ze gaan dus ook Windows à la vibe-coding carte herschrijven? Serieus?
Met alle foute code die dat uitspuugt en dan op de toon van een totaal onhaalbaar target dat het onmogelijk maakt om de correctheid van de door AI geproduceerde Rust code te verifiëren?

Wat zijn ze toch dom bij Microsoft he? Denk je nu werkelijk dat ze dat soort dingen niet betrekken bij dit soort beslissingen?

[R4gnax]

Hun target is 1 engineer, 1 miljoen LoC, 1 maand.
Weet jij hoe lang een propere code review op high level code duurt?
Laat staan system-level code?
Dat ga je in een maand tijd voor 1 miljoen regels code nooit redden. Ja- tenzij je ook AI gebruikt om de code te reviewen. (Quis custodiet ipsos custodes?)

Om dit even kristal helder te maken - als we uitgaan van een 40u werkweek en 8u per dag, met gemiddeld 22 werkdagen op een maand, betekent het dat je ruimschoots 5600 lines of code per uur moet reviewen. Non-stop. Dus ervanuit gaande dat je geen enkel ander werk hoeft te doen. (Zoals de AI prompten om de code te herschrijven. Unit tests inspecteren. Dagelijkse voortgangsvergaderingen etc. etc.)

Dit target is dus complete onzin. TOTAAL onrealistich en van god los.
Dus ik kan met redelijke stelligheid zeggen: als ze dat soort zaken er al bij betrokken hebben, dan zijn die summier genegeerd met een magere 'trust in the plan'.

Want hey- dat is ook precies wat Satya Nadella tijdens zijn schrijven a/d medewerkers van het bedrijf mededeelde. Dat was niet veel meer dan een politiek-correct verbloemd ultimatum: je laat AI het werk doen, of je vliegt er uit.

[Reactie gewijzigd door R4gnax op 23 december 2025 12:35]

[Blokker_1999]

1 miljoen op een maand, dat zijn er gemiddeld 50 000 per dag of meer dan 6000 per uur. En ja, niet elke lijn code is complex, niet elke functie is moeilijk te begrijpen. Maar zeker in een OS zoals Windows kom je code tegen die er mogelijks al decennia in zit, waarvan niemand de achtergrond nog goed begrijpt, waarom er bepaalde beslissingen zijn gemaakt. En om dan aan zo een sneltempo er door te gaan?

En dan moet je nog de engineers vinden die het willen doen. Na enkele dagen reviewen aan dat tempo wordt je gewoon gek.

[foobar79]

Precies, 1.5 seconde om een regel te lezen is al snel. Nu is het ook nog eens code die je niet kent die je moet gaan begrijpen EN je moet het eigenlijk vergelijken met de originele C code om zeker te weten dat er geen dingen verloren zijn gaan. (Dus in de 1.5 seconde moet je de originele code ook nog eens lezen)

Daarnaast heb je nog tijd nodig om aanpassingen te doen etc.

[R4gnax]

Om het wat meer tastbaar te maken: aangenomen dat een boek gemiddeld 50 regels per pagina heeft, komt dit neer op 110 pagina's aan complexe dissertatie lezen en volledige doorgronden per uur. Dus minder dan één minuut per pagina. (Net iets meer dan een halve minuut per pagina, om precies te zijn.)
Waarbij je even in het achterhoofd moet houden dat je hier niet lineair van voor naar achter aan het lezen bent, maar eigenlijk elke 2e of 3e regel een voetnoot referentie krijgt die terugwijst of vooruitwijst naar een andere pagina die je 2u geleden gelezen had, of pas einde dag bij aan zou belanden.

Have fun, with a capital FU.

[Reactie gewijzigd door R4gnax op 23 december 2025 13:11]

[Khrome]

Het is eerder te vergelijken met elke 2 uur House of Leaves lezen en begrijpen

[Tjolk]

6000 regels is zeg maar De Hobbit in hardcover.

Probeer je eens voor te stellen dat je De Hobbit in een uurtje uitleest. Dat je vervolgens voor lunchtijd ook nog eens de hele trilogie van LoTR hebt gelezen. Dat is al godsonmogelijk. En dan niet alleen lezen, maar ook begrijpen, relateren aan ander werk van Tolkien en de wereld van fantasy. En de fouten markeren en oplossen.

Dit is gewoon totale BS :Z

[R4gnax]

En dan moet je nog de engineers vinden die het willen doen. Na enkele dagen reviewen aan dat tempo wordt je gewoon gek.

Ik denk dat je al gek moet zijn om de positie überhaupt aan te nemen.
Of een complete nitwit die niet kan rekenen.

Dus dan weet je al precies wat voor kaliber er op deze posities zal komen te werken.
En dus niet gehinderd door enige vorm van kennis gewoon ja en amen zal knikken op alles wat de LLM uitspuugt.

[martijnvanegdom]

[sarcasme mode]

Wat denken jullie toch allemaal in jullie Nederlandse bubbel zeg 40 uur per week?

Het maakt niet uit hoeveel tijd je nodig hebt.. het target wat je moet halen is gewoon 1.000.000 LOC

dus als je gaat naar 12 uur voor 7 dag, dan heb je meer dan 2x zo veel tijd per regel! Of als je naar 16 uur per dag, 7 dag per week gaat heb je zelfs 3x zoveel tijd! Dus dat is echt prima te doen!

[R4gnax]

En opeens snappen we waarom MS al die entitled Amerikaanse werknemers de laan uitstuurt en vervangt door H1Bs. Niet omdat ze goedkoper zijn; maar omdat ze het gewoon accepteren om volledig geexploiteerd te worden. Buk en ontspan. /s

[Reactie gewijzigd door R4gnax op 23 december 2025 14:07]

[!mark]

Bij een werkweek van 40 uur (waarbij je 100% van de tijd aan het reviewen bent, ofwel onmogelijk) zou je dan ~100 regels per minuut moeten doorlopen om op 1 miljoen te komen. Ook met een 996 achtige werkweek zoals helaas in het Amerika van nu weer acceptabel lijkt te worden zit nog op ruim 50 regels per minuut.

Zelfs als je een boek leest ter ontspanning lees je bij lange na geen 50 regels per minuut weg, laat staan dat je dit zou moeten halen tijdens het reviewen en beoordelen van iets.
M.a.w compleet onmogelijk zonder ook het review proces aan AI uit te besteden.

[JacOwns7]

Nou jongens...
The year of the Linux desktop lijkt er dan wellicht eindelijk te komen, maar wel even op een andere manier dan gedacht...

!RemindMe 25 jaar..

Denk niet dat dit in de nabije toekomst gaat gebeuren zolang de distroboeren bij elke poep en scheet die dwars zit een nieuwe distro starten die het "net even weer anders doet"

Denk niet dat AI ingezet word op de manier zoals je hierboven aangeeft.

[R4gnax]

Denk niet dat AI ingezet word op de manier zoals je hierboven aangeeft.

Ik denk dat jij de schaal van 1mil LoC / maand niet snapt, en niet doorhebt dat zoals ik het aangeef de enige manier zou zijn om dat debiele target te halen.

[Mizgala28]

The year of the Linux desktop gaat er niet komen, simpel.

Maar met de hoeveelheid mess-ups die MS pleegt zou ik willen dat ik fout zat.

[Llopigat]

Haha right. Ze krijgen het niet eens voor elkaar om een paar control panel schermpjes volledig te vervangen in 10 jaar tijd.

[tweak-eddie]

• Of een goed werkende zoekfunctie
• Of een nieuw filesysteem
• Of een standby/ sleep mode die goed werkt, zodat je niet na 2 dagen een lege laptop uit je tas trekt
• Of een goed werkende overstap naar ARM/RISC
• Of een bluetooth stack die goed functioneerd (elke telefoon kan dat)

Wel CoPilot die niemand wil en nieuw design, leuk maar maak eerst de basis is voor elkaar.

Eigenlijk beschamend dat Apple inmiddels als jaren op ARM draait en dat dat vanaf het begin goed heeft gefunctioneerd (voorzover ik weet).

[Reactie gewijzigd door tweak-eddie op 23 december 2025 12:49]

[WhiteSnake76]

Zitten nog steeds best veel bugs in Windows 11, ik laat mijn Main systeem nog ff lekker op Windows 10 draaien.

Waar ik me echt aan irriteer is dat er vaak een bug is, die ze fixen, maar dan na een poos gaat er weer iets mis bij M$ en krijg je weer het zelfde euvel...

[moimeme]

Grappig gedachte, al die draaiende dc om C/C++ bugs om te zetten in rust.

[WhiteSnake76]

Hoop dat ze het een keertje voor elkaar krijgen om het weer net zo goed als bij bvb 7 of 10 te krijgen, maar denk dat we moeten wachten tot Windows 12, Rust of geen Rust, M$ maakt zelf een hoop van die fouten die bugs veroorzaken.

[Blokker_1999]

Toch een paar bedenkingen, want ik denk niet dat dit het doel is van Microsoft.

Het is geen persbericht, het is geen communicatie vanuit het bedrijf. Het is niet eens een vacature die open staat, maar de beschrijving van 1 man die iemand wenst aan te werven voor zijn team binnen Microsoft. Zijn team is zelf ook niet verantwoordelijk voor het schrijven van de code van Windows, Office of andere grote software stacks voor zover ik kan zien, maar de beste man valt onder het kernteam van AI en zijn team ontwikkelt dus tools om developers te helpen.

Hij mag dan wel persoonlijk als doel hebben om C/C++ te elimineren, maar dat ga je natuurlijk niet zomaar doen op een historische code base. Alles wat nieuws is kan je wel in andere talen schrijven, alles wat blijft evolueren kan je vastnemen. Maar de oude APIs, de oude tools, de dingen die Microsoft al jaren niet meer aanraakt, die uitontwikkeld zijn en waar eigenlijk geen bekende bugs meer inzitten, waarom zou je die zelfs maar willen laten herschrijven door een AI systeem?

Ambitieuze doelstellingen zijn leuk. Je maag gerust hoog mikken met je doelstellingen, maar als je realistisch bent, dan moet je ook realiseren dat je in de praktijk nooit alles zomaar aanpast. En al helemaal niet op slechts een handvol jaren.

[R4gnax]

Het pijnlijke is dat dit van een positie van autoriteit binnen het bedrijf komt. Iemand die er al 30 jaar zit en zich tot een gekwalificeerd leidinggevend persoon heeft ontwikkeld.

Die zou beter moeten weten. Maar helaas niet. AI Kool-Aid voor iedereen, blijkt.

[SPee]

Mijn eerste gedzchte was dat die post nep was. Mijn tweede dat die persoon liep te trollen.

[The Zep Man]

Microsoft wil dit in 2030 rond hebben en gebruikt daarvoor AI.

Gezien de impact van LLM nu bij Microsoft op hun kernproducten en dat Rust niet per definitie bugvrij is (net als iedere andere programmeertaal), is er voorlopig voldoende werk voor systeembeheerders.

[Reactie gewijzigd door The Zep Man op 23 december 2025 16:42]

[sweetdude]

En ze gaan Windows 12 niet uitbrengen, maar gaan hem ME noemen

[Prince]

"Microsoft Windows Vibe Edition"

Neen, serieus, Goed getrainde AI kan op zich stap voor stap zaken omzetten naar Rust en vast nog wel goed. Maar dit gaat geen verbeteringen toevoegen in de code, noch op inhoudelijke fouten controleren.

Het enige wat goed is, zijn de memory safe voordelen en een goede compiler. Ze zullen dit vast wel goed checken - doen ze toch altijd ;-)

Ik vraag me wel af wat dit als gevolg heeft voor de mensen die bij MS werken die C/C++ developer zijn. Moeten deze nu allemaal Rust gaan leren en als primaire taal gebruiken?

[hackerhater]

Gezien hoe oud sommige code zal zijn, zullen er ongetwijfeld bepaalde hacks in zitten die niet 1 op 1 te vertalen zijn naar Rust (of welke taal dan ook).
Dat is al lastig voor gespecialeerde engineers, dat door een een code generator (LLM's) te laten doen is vragen om ellende.

[CAP-Team]

#Me2 :D

[WigaDan]

Lol

[downtime]

Ik snap het niet helemaal. Als AI slim genoeg is om een hele C codebase te herschrijven naar goede Rust code, waarom is het dan niet slim genoeg om de bestaande C code foutvrij te maken?

[TinusH777]

Het managen van pointers zit niet in 1 procedure. 1 object kan door de hele applicatie gebruikt worden.

Per pointer moet je dus bedenken waar en wanneer je het object kan weggooien.

Ongezien gebruik van een object (door een andere ontwikkelaar), leidt er toe dat je een object weggooit terwijl het nog gebruikt wordt door een ander object.

Dat is niet te zien aan coding, want het heeft te maken met timing.

[MadEgg]

En dat lost Rust opeens op? Rust maakt het zichtbaar. Dat kan C++ ook, met shared_ptr en dergelijke. Dat verandert de API wel, net als herschrijven in Rust zal doen. Welke van de twee is makkelijker?

[TinusH777]

De native systematiek voor pointers en memory management zijn fundamenteel anders in Rust. Dat is eigenlijk de reden waarom de taal is ontwikkeld.

In C++ heb je discipline nodig van de ontwikkelaar om iets speciaals te gebruiken om geen dangling pointers of memory leaks te krijgen door Rust constructies na te bootsen.

Dus je moet alle code reviewen om te checken of een ontwikkelaar iets heeft gedaan wat buiten de patterns valt.

Met 5000 ontwikkelaar die aan Windows bouwen, kun je er niet vanuit gaan dat dat allemaal goddelijke seniors zijn. Daarom heeft Rust de voorkeur, omdat die de patterns afdwingt.

Het is een investering, maar dan kan die code ook weer 25 jaar mee.

[MadEgg]

Ik snap wel dat Rust inherent veiliger is met memory, maar een rewrite kan alleen impact hebben op de code die de compiler aanraakt. Alle API’s zullen daarmee moeten veranderen (of ze blijven exact even onveilig als ze nu zijn). En daarmee dus ook alle gebruikers van de API. Dat is nogal een klus.

Eén applicatie is te managen, maar hoe meer je met libraries en componenten gaat werken hoe bewerkelijker het wordt.