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.

Door Jasper Bakker

Nieuwsredacteur

23-12-2025 • 12:04

78

Submitter: Tribits

Reacties (78)

Sorteer op:

Weergave:

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]

Misschien handig als je er dan ook een bron bij geeft?
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.
En voor diegene die 'm niet bij z'n initialen kennen: Stephan T. Lavavej, Dé Microsoft engineer voor hun C++ Standard Library implementatie.
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]

Ik vind het ook nogal absurd dat dit niet ergens argwaan oproept voor publicatie maar goed dat is persoonlijk waarschijnlijk.
Is zeker niet absurd, ik zou ook verwachten dat een tech redactie dit onmiddellijk herkent als onzin.
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.
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.
"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.
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]

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]

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.
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...
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.
Die eis was er al bij kritieke Defensie zaken. Die zijn daarom vaak al in Ada geschreven.
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.
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.
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.
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.
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.
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 8)7
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.
Ik denk dat ze best wat kunnen besparen als MiCo de huidige CEO vervangt.
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.
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...
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.
Voordeel? Ze gaan helemaal niks doen behalve het hele OS door een LLM gooien. Denk niet dat het nog opstart daarna 8)7
Tja hit is een

Lost language model 😅
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').
Vooral leuk als de LLM het nodig vindt code als 'unsafe' aan te merken...
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.
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]

Haha right. Ze krijgen het niet eens voor elkaar om een paar control panel schermpjes volledig te vervangen in 10 jaar tijd.
  • 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]

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...
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]

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?
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]

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.
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.
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]

Het is eerder te vergelijken met elke 2 uur House of Leaves lezen en begrijpen :p
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.
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
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.
[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!
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]

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.
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.
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.
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]

En ze gaan Windows 12 niet uitbrengen, maar gaan hem ME noemen :+
"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?
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?
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.
Wat een onzin, Rust is zelf ook verre van veilig, dus code vervangen waar niets mis mee is en wat al vaak volledig gecontroleerd is met iets nieuws zou erns ontzettend domme zet zijn. Typisch gedrag van onervaren developers die weer een zoveelste fab voorbij zien komen.

Om te kunnen reageren moet je ingelogd zijn