Microsoft wants to replace its entire C and C++ codebase, perhaps by 2030

Microsoft wants to develop tech that could translate its codebase to Rust, and is hiring people to make it happen. “My goal is to eliminate every line of C and C++ from Microsoft by 2030,” Microsoft distinguished engineer Galen Hunt wrote in a recent LinkedIn post. “Our strategy is to combine AI and Algorithms to rewrite …

[Brl4n]

lol. yeah that's the problem. blind leading the dumb leading the dumber blind. how are they still a company and who pays their hard earned money for anything they make?

[beast666]

Thankfully it's fake

[coredump]

Is it, though?

E.g. "fake" implies the post was fraudulent from the jump, whereas the follow-up sounds more like back-peddling and behind-covering after a lot of bad press.

Either way, I hope they forge ahead anyway and continue marching along the path as announced. It's likely to be interesting, if not amusing.

[steviesteveo]

It's fake until the KPIs look good then it's immediately back

[ITMA]

To quote from "Yes Minister"....

"Never believe anything until it's been officially denied"

So it MUST be true!

[Roland6]

Aside: scroll down and you get to another interesting piece “ Windows 11 has a bigger problem, and it’s WebView2 or Electron”…

[Pulled Tea]

“1 engineer, 1 month, 1 million lines of code”? That's not an engineer, that's a patsy.

That's not dev empowerment, that's a moral crumple zone when some hallucinating chatbot codes in a major security vulnerability.

[stiine]

Re: “1 engineer, 1 month, 1 million lines of code”? That's not an engineer, that's a patsy.

You used the singular. You're not pessimistic enough.

[Paul 76]

Re: “1 engineer, 1 month, 1 million lines of code”? That's not an engineer, that's a patsy.

On my sums, if there are 31 days in the month and the engineer works 24/7, that's 22 lines of code a minute.

[Gary Stewart]

If it aint broke...

Well it is broke and given Microsoft's track record the best that they could do is break it more and take a long time to do it. This is not a good time to be a Microsoft OS beta tester, AKA customer.

[Tim99]

Re: If it aint broke...

When I was a Microsoft customer (and wrote Windows shrinkware), I often thought that I was an alpha tester…

[Alumoi]

Re: If it aint broke...

Depending on your version of Windows, it's beta (10) or alpha (11) tester. For Office it's alpha all the way.

[FirstTangoInParis]

Re: If it aint broke...

> For Office it's alpha all the way.

They’ve only had 18 years to make the code base better. But no, the crayons team wanted a constant stream of new shiny stuff which was totally unnecessary and wasted effort.

[David Hicklin]

Re: If it aint broke...

So now the AI will hard bake into the code all the cludges, bodges and workarounds that have infested windows since 1.0 And along the way all the coding notes (if any!) on why will be lost along the way...

And of course it won't work now its "safe", so more bodges will be needed.

[Apprentice Human]

Micro$loth strikes again

Low pay, high workload fixing AI hallucinations and slop.

Glad I'm retired and never worked for the circle of hell that Dante missed.

[Bebu sa Ware]

Re: the circle of hell that Dante missed

"the circle of hell that Dante missed."

I always assumed the more obnoxious parts of IT were to be found up Satan's arse — a virtual 11^th Circle as it were.

Which understandably Dante and Virgil quickly passed without further comment or hazard to their immortal souls.

[thames]

One more thing

This is one more thing to add to your list of "things that are not going to happen".

Microsoft have yet to demonstrate replacing even one significant program that they derive revenue from by using AI to rewrite something that was in C++ to something written entirely in Rust. They have re-written bits of programs in Rust, but that's it.

One programmer is not going to produce 1 million lines of finished code every month, AI or no AI. Of course they may get an AI to submit variations on the same 10 lines of code 100,000 times in an effort to hit a numerical target, but that isn't going to get them to an all-Rust program.

What they are doing sounds more like a desperate effort to promote customer use of AI than a serious goal for themselves.

[jake]

Re: One more thing

"sounds more like a desperate effort to promote customer use of AI than a serious goal for themselves."

DING DING DING DING DING!

We have a winnah!

[Pickle Rick]

Re: One more thing

> 1 million lines of finished code every month

Now, now thames, no one mentioned anything about "finished" - that places unnecessarily restrictive caveats on the project and the Primo Promptstitute undertaking it. Modern project management best practices are not bound by such trivial concerns as "correctness" and "functionality" to be "successful", ie. finished. (cf. the Civil Service Pension Scheme - delivered on time!)

[Steve Davies 3]

The code might be [cough][cough] finished

but how many new bugs will be introduced due to deficiencies in the AI model?

Don't hold your breath people.... This 4 year deadline will only result in the following:-

- new bugs and no one inside MS to properly test the code. Result? more Zero Day errors.

- increased license fees for the new 'Rusty' product (marketing will be wetting themselves over this)

[Acrimonius]

Re: The code might be [cough][cough] finished

Well, they will now have an excuse for the constant stream of bugs that will follow - it's development, just need a bit of time to iron things out and settle in

[Paul 76]

Re: The code might be [cough][cough] finished

AI Generated testing.

Here it is.

10 PRINT "It works !"

[herman]

Re: The code might be [cough][cough] finished

20 goto 10

[Miko]

Re: One more thing

They said nothing about the current lines of code, just the amount of output.

So if, say, one engineer can indeed translate 1000 lines of code a month into Rust, and the output for the month is (with AI help) 1 million lines of code, the vision is reached.

But if the Windows codebase has, say, 50 million lines of code, translating it to Rust would still require 50000 engineer-months of effort (even assuming the work doesn't slow down after the tricky bits and interactions start piling up, which they certainly would). So the end result will be a Rusty Windows 10 composed of some 50 *billion* lines of code. AI efficiency!

[Roo]

Re: One more thing

One of the hidden incentives of transliterating code from one language/toolchain to another an incentive to reduce the workload by leaving the cruft behind. Having an AI identify and strip out the cruft should be very doable given the intrusive instrumentation that Microsoft has woven into their platform for many years now.

[Not Yb]

Re: One more thing

If they did strip out the cruft, much of the OS would disappear.

[Mostly Irrelevant]

Re: One more thing

I would like that very much.

[Roland6]

Re: One more thing

Cruft removal requires an understanding of not just what the code is for, but also what is obsolete, unnecessary and plain wrong.

[Bebu sa Ware]

Re: One more thing

"But if the Windows codebase has, say, 50 million lines of code, translating it to Rust would still require…" 50 engineers ?

Which is pretty close to the plot of the (recently) late Tom Stoppard's 1967 radio play Albert's Bridge. :)

[JoeCool]

Re: One more thing

Nice bit of alliteration there.

[martinusher]

History Repeating Itself

This isn't the first time I've come across management who think that the solution to a disorganized code base is to recode them into the latest and greatest language.

[munnoch]

Re: History Repeating Itself

In my experience its usually the developers themselves who are so unhappy with the mess that's resulted from unending demands to deliver something, anything no matter how quick and dirty, pleading to be allowed to start over with a clean sheet, sometimes in a new language or with a new framework. Just give us 3 months to rewrite and then we promise we'll get back onto your pipeline of unreasonable requests with renewed vigour.

When there is no balance of power between product owner and developers its inevitable it will all collapse, its only a question of how long it manages to stumble forward for. Magic fairy dust can't fix that interplay.

[Anonymous Coward]

AI Plus The Agile Manifesto.....A Recipe Made In Hell!

Quote: "......product owner and developers......"

@munnoch

Hah....."agile".....and no mention of all those "user stories" which turn out to be incomplete...........

..........and all the stories which never made it onto "the wall" in the first place!

Hah.....I know....lets get "AI" to compare the code with the "user stories"!

At least one product is going to change from "Office" to "Orifice"....as the old joke has it!

[Roland6]

Re: AI Plus The Agile Manifesto.....A Recipe Made In Hell!

Back Orifice was good and useful tool.

[Blazde]

2030 Goals

As long as we're already smoking crack and pulling numbers out of our arses, why not just go full pelt to make The Singularity happen by 2030? Rewriting a 50 year old tech giant's entire codebase will be a mere microsecond's effort then.

[Pickle Rick]

Re: 2030 Goals

I'm glad I read that _before_ picking up my coffee! [Selects appropriate icon.]

[Always Right Mostly]

That job "offer" really confirms it for me that were I younger and starting out I'd run as fast as possible away from a career in tech.

[Steve Davies 3]

re: I'd run as fast as possible away from a career in tech.

with anything even remotely related to Microsoft.

That seems better does it not?

[Jou (Mxyzptlk)]

Using Rust ist not the solution per se...

The language is safer, but Microsoft will manage to use it in a way that will break safety and stability. There is no ThRust, so much stuff from ~2020 on shows. Even some core things near or even within kernel space, which worked fine, are now broken. And more will break.

[cdegroot]

Re: Using Rust ist not the solution per se...

Rust is a reasonable answer for when you really need low level safety. Issue is: 99% of the time, you dont need that. There are many, many languages much better suited for application writing (heck, C# could probably be close to self-hosting) but somehow "rewrite to Rust" is this decade's craze. its just as bad a choice as C, C++, and Golang were.

But yeah, it's clear that pot is legal in Washington state. They're partaking of it a lot in Redmond.

[Mostly Irrelevant]

Re: Using Rust ist not the solution per se...

Core parts of an OS are that 1% case.

[Anonymous Coward]

Re: Using Rust ist not the solution per se...

Which is an area researchers have discovered you need to disable the memory safety features to do some of the stuff OS’s need to do….

[stiine]

Re: Using Rust ist not the solution per se...

Will they wrap the entire codebase in unsafe {} ???

[Anonymous Coward]

Re: Using Rust ist not the solution per se...

It works as it is 'legal' in the world of Rust !!!

Joking aside, some bits will require this unless substantial effort is made to rewrite things 'properly' !!!

'Properly' is in the process of being defined ... this will take some time ...

Please be patient, have a coffee & put your feet up, read War & Peace (the Swahili version) ... a chance to pick up a new language for some !!!

(FYI: There are approx 200 million Swahili speakers, so not exactly small in number !!!)

:)

[EvaQ]

“Our North Star is ‘1 engineer, 1 month, 1 million lines of code.’”

... google hit: "There is approx. 50 Million lines of Code in Windows 10".

So hire 1 engineer, keep him/her working for 50 months, and ... done! Indeed in 2030.

Or: the pointy haired boss has a cunning plan, and he will hire 50 engineers, and expect it to be done in a month time.

Nice!

/s

[Giles C]

Re: “Our North Star is ‘1 engineer, 1 month, 1 million lines of code.’”

That is just windows 10, what about the myriad of other products that they have.

[Jou (Mxyzptlk)]

Re: “Our North Star is ‘1 engineer, 1 month, 1 million lines of code.’”

You know that developers developers developers developers scale linear with increased number. Take 200 of them, and those 50 million lines are done in two weeks! And I get my management bonus! And then they can convert the other products at more speed due to the acquired knowledge, double bonus!

[Rahbut]

Re: “Our North Star is ‘1 engineer, 1 month, 1 million lines of code.’”

I think you're onto something. Take it to its logical conclusion and add enough developers and you eventually create some kind of coding time travel paradox...

[Locomotion69]

Re: “Our North Star is ‘1 engineer, 1 month, 1 million lines of code.’”

It is not just Windows, it is the complete codebase - it is hundreds of products, some not even designed by themselves but acquired in a merger/takeover.

Not even considering used libraries, which may be statically linked, so different versions from the same lib are used and updates are not compatible, etc.

It should be called Project Snakepit

[Antron Argaiv]

Re: “Our North Star is ‘1 engineer, 1 month, 1 million lines of code.’”

Microsoft has just invented auto-enshittification!

Also: they could start by removing a lot of cruft from Windows...

[MonkeyJuice]

Re: “Our North Star is ‘1 engineer, 1 month, 1 million lines of code.’”

Start with the bootloader and follow the dependencies from there.

[AnonymousCward]

LLM can’t do worse for the bootloader

I really doubt an LLM could do a worse job than the humans at Redmond already did.

It is the only bootloader which reboots each time you pick a non-default OS only after you’ve already had to input your BitLocker password or PIN (because TPM-only is basically pointless) to get to the menu which lets you pick which OS to boot in the first place. That means picking any non-default option means typing in a PIN/password twice, and when doing updates, that can end up being up to four password inputs. Oh, and it relies upon the BIOS to initialise the USB stack prior to inputting a BitLocker password too.

They should seriously consider adopting GRUB, which doesn’t have any of these issues.

[Eric 9001]

Re: LLM can’t do worse for the bootloader

GNU GRUB is GPLv3-or-later and requires that you respect the users freedom (which includes providing instructions and/or keys for unlocking any implemented digital handcuffs, just like the GPLv2), which goes against microsoft's plans and goals, thus they will not use GRUB.

[Bebu sa Ware]

Our North Star is ‘1 engineer, 1 month, 1 million lines of code.’

The choice of "North Star" probably isn't the soundest as the Earth is nearly as wobbly as Microsoft products and has had succession† of Pole stars over the millenia.

I would append to this nonsense "1 manager, 1 hand, 1dick…" — Somehow I don't think these tossers will pull it off… or they will but not the 10⁶ lines of code.

No reflection on Rust or the Rust developer community intended.

_{† or precession. ;)}

[Dinanziame]

Re: Our North Star is ‘1 engineer, 1 month, 1 million lines of code.’

They would have to pay me a lot more than that to work with such a goal...

[A Non e-mouse]

Not the holy grail

Whilst Rust will prevent some errors (Mainly around memory use), it's not going to prevent all errors. It can't prevent logic/algorithmic errors.

Rewriting an existing codebase in a new language is just going to add a new class of bugs - and that's assuming little to no use of "unsafe"!

And what about Microsoft's fastidious addiction to backwards compatibility - warts 'n all?

[Doctor Syntax]

Re: Not the holy grail

"warts 'n all?"

Warts especially. That bit will be assured.

[werdsmith]

Re: Not the holy grail

Whilst Rust will prevent some errors (Mainly around memory use), it's not going to prevent all errors. It can't prevent logic/algorithmic errors.

People keep feeling the need to point this out but the Rust people have never claimed it does any more than help to prevent memory errors.

[bazza]

Re: Not the holy grail

Myriad studies have found that a large proportion of bad bugs in software are related to memory mis-use. Using an alternative to C/C++ that is memory safe just makes sense, because of the ease with which such bugs are eliminated. Even code as venerable as the GNU coreutils was found to not be bug free (after all this time) when someone started a reimplementation in Rust.

I'm firmly in the camp that Rust Makes Sense, if you can have the inclination to use it.

However, I do have some reservation about what MS are doing. There's a lot more to Rust than simply "it's memory safe". Unlike C/C++, it has a built in Actor Model and CSP mechanism (or at least there's a crate for such a thing); the latter is what make Golang so appealing. If you take C/C++ and just translate it, what they'll end up with is a Rust translation of their existing C/C++. However, that'd probably miss out on the opportunity to re-think what the code is actually trying to do, and potentially miss out on using language features that Rust has and C/C++ do not. Granted, their "AI" approach may be smart enough to do that re-thinking, but that feels like a bit of a stretch.

I'd also be interested if they'd turn on Rust's "Fearless Concurrency".

[Eric 9001]

Re: Not the holy grail

>Myriad studies have found that a large proportion of bad bugs in software are related to memory mis-use.

Source?

Other studies have found that for n hundred lines, y amounts of bugs are typical (now if only I had the connection to find those studies) - which seems to imply that the more syntactical tokens, the more bugs (it seems that the typical rust program needs 2-50x more tokens to do the same things as C due to heavy use of crates).

I agree that memory bugs are now much easier to find with current tooling (which makes papers on such found bugs common), but it's a waste of time to write papers instead of fixing the bugs to fix the problem.

Most bugs seem to actually be logic bugs (which are hard to find), which Rust's borrow checker seems to enforce implementing by design.

>Even code as venerable as the GNU coreutils was found to not be bug free

Yet more bugs were found and fixed, making GNU coreutils even better.

>when someone started a reimplementation in Rust.

The rust coreutils is a buggy mess and it doesn't even pass GNU coreutils test suite.

It's important that existing GNU bash scripts continue to work and are portable (rust is not portable - it only works with the limited number of CPU architectures that LLVM supports and even then, you can only expect 3 architectures to usually work) and it really isn't that important if there are memory vulnerabilities, as the free software in the scripts that serve you isn't going to exploit those is it?

[RJW]

Why use AI to convert from c/c++ to rust?

Why would you use AI to convert from c/c++ to rust? When you could write a compiler to do it, that would do the conversion 100% right. No AI hallucinations would be introduced to your code base. Probably faster and using less data centre compute time and energy.

[m4r35n357]

Re: Why use AI to convert from c/c++ to rust?

Already in progress: https://github.com/immunant/c2rust

Pretty basic ATM, it transpiles to "Rust" that looks like the c code (it is full of glibc references etc), but they intend it to convert to more "idiomatic" Rust in the (near) future.

As it is, I hope M$ have a better starting point than that ;)

[Alumoi]

Re: Why use AI to convert from c/c++ to rust?

AI will write the compiler.

[7teven 4ect]

Re: Why use AI to convert from c/c++ to rust?

ask not who will write it, or in what?

ask, instead, who will test it?

then ask who will test the tester?

then ask if it is turtles all the way down?

then ask for another glass of egg mogri.

[Paul 76]

Re: Why use AI to convert from c/c++ to rust?

Numpty.

All you have to do is type into ChatGPT "Convert all the code at https://github.com/microsoft to Rust with 100% compatibility and fix all the outstanding issues while you are at it".

That'll work fine.

[abend0c4]

Re: Why use AI to convert from c/c++ to rust?

A compiler could translate the syntax, but that in itself may be a retrograde step. Since the C code was written without any notion of Rust's lifetime model, you'll likely just get a slew of messages warning you of potential misuse of references, the vast majority of which would never be problematic. Your task, then, is to go through every one and determine whether or not it's a genuine error in the original code or to fix the declarations so that the code compiles cleanly. That's a vast amount of effort to undertake manually. And that's before you consider the difficulties of correctly interpreting the general type abuse and void* laxity of a lot of C code.

Let's assume for a moment that AI can spot dangling pointers in heavily nested subroutines with regular calls outside the codebase to which it has access. If it can't then the AI approach is doomed to failure, but we'll come to that. In that case, simply detecting and fixing errors in the existing codebase (without the blizzard of false positives) is a modestly easier task than detecting and fixing those errors while simultaneously transforming the syntax into another language. It's also a much lower risk approach as it is much easier for humans to review the code changes, it avoids a lot of retooling and minimises the potential impact on your unloved and neglected products that consume the C code in ways that only become apparent when it's no longer there. It's the approach an engineer, rather than an evangelist, would prefer.

However, the most likely case is that AI's ability to infer the difference between a safe and unsafe reference is imperfect. Given the maturity of much of Microsoft's code, the number of errors liable to cause significant problems will be relatively low (many of the more recent howlers are to do with code that has been gratuitously rewritten). Even if you have faith in the AI, it would have to be almost perfect for the entire process not to introduce errors at least as numerous as the ones it fixes. Given the deteriorating state of QA, there's a very significant chance you end up in a worse place. In short, it's a pipe dream.

I don't know what it is about the IT industry that causes the constant desire to start afresh with a clean slate, but I've seen a large number of great resets and they've almost all overspent, failed to achieve their goals and left fundamental problems unsolved, though in new and different ways. if software developers built bridges they'd be constantly closed for reconstruction.

[Doctor Syntax]

Re: Why use AI to convert from c/c++ to rust?

"Given the maturity of much of Microsoft's code, the number of errors liable to cause significant problems will be relatively low (many of the more recent howlers are to do with code that has been gratuitously rewritten)."

If that were indeed the case the best approach would be to go back to an earlier version as the starting point, reimplement that in Rust and then roll forward adding the intended functionality of the later versions. Or just leave it there without all the slurping and user hostility.

[Crypto Monad]

Re: Why use AI to convert from c/c++ to rust?

The only reference for what this code is *supposed* to do is the code itself. Therefore, the best that can be achieved automatically is to faithfully reproduce all the existing bugs - which may require writing very tortuous Rust code to achieve.

OTOH, if the objective is to write idiomatic and safe Rust, then how will the AI tell the difference between a bug, where behaviour has to be changed to match intent (such as removing a security flaw), and a feature (i.e. some aspect of behaviour which consumers depend on, and cannot be simplified away)?

[sarusa]

Re: Why use AI to convert from c/c++ to rust?

Because f@#ing Nadella only rewards cult members who fountain 'AI!' feces from all holes over all surfaces. This is very much tail wagging the dog.

Vibe code lots of Windows updates with zero testing that take down millions of PCs? You're a star performer, you're getting promoted!

Oh, you're a strictly methodical engineer who hand writes his code and seriously considers pointer lifespans and best data structure for a particular problem and whose code never fails? You're getting demoted for not deep throating Nadella's new God.

It doesn't matter what the actual problem is, you just need to slap 'AI' on your dick and wave it around to succeed at Microsoft. They obviously have not cared how sh@tty this makes their products since at least 2021.

[Fruit and Nutcase]

systemd + "agent-p"

Given that "agent-p" works for Microsoft, may we one day see what him using the tooling to convert systemd from C to Rust?

[Not Yb]

Re: systemd + "agent-p"

We could call it CRust-d. Like the clown.

[Bluck Mutter]

this used to be my bag..

... porting various apps from one language to another.

What's missing here is:

- the planning on what needs to be ported first...as with any application (OS or not) there is an onion shell and generally you need to start at the core and work out. You can't really attack all layers at once cause you have no idea how the layers above and below layer X has changed and what issues they throw up

- how do you test each layer when it has dependencies on the completion of those below it (esp true of an OS)... thus in many/most cases you can't test the converted code until it's dependencies are ready (i.e. you get bottlenecks in delivery)

So it's not just a matter of converting the code, the hard part is the conversion template (i.e. the agreed target syntactical reformat for each occurrence of the source syntax..this is upfront work), the conversion plan (how to attack the onion), the test plan, the test data, the performance plan, the stress test plan etc. Existing stuff like performance/stress suites might not be valid given the new language will react differently under stress from the old language.

No way they can deliver this with any degree of quality or consistency in code structures in that time frame (or ever)

I well remember being called into a very large EU bank where they were porting a mainframe app (cobol/cisc/jcl etc) to Java. What the idiots didn't do is take some small core functions and see if it scaled ok with Java. So the spent 3 years (offshored resources) converting the application to find the somewhat completed Java version had no performance... this was an intrinsic issue with Java so the project was abandoned.

A little bit of prototyping/proof of concept would have shown them it wasn't going to work or might have shown up some Java hacks that would help with the performance bottlenecks during the early stages (i.e. part of the conversion template).

Bluck

[Will Godfrey]

Re: this used to be my bag..

Waitaminit! Are you suggestion Microsoft code actually has core {cough} logic {cough}?

I thought it was just a rat's nest of random bits of 'stuff'

[Doctor Syntax]

Re: this used to be my bag..

"Are you suggestion Microsoft code actually has core {cough} logic {cough}?"

Let alone planning and testing.

[Will Godfrey]

Re: this used to be my bag..

Well, they actually have millions of testers - they call them 'users' :(

P.S. I call them victims.

[Bebu sa Ware]

Re: this used to be my bag..

"{cough} logic {cough}" —

Caught my eye as it is the {precondition} statement {postcondition} format of weakest precondition semantics.

I imagine "cough" is the peculiar Microsoft predicate that requires nothing and is established by anything. ;)

[DexterWard]

Re: this used to be my bag..

Senior management hate being told something isn’t going to work, even if you present good evidence, in fact especially if you present good evidence. They rely on magical thinking, and having that contradicted enrages them.

[unix.beard]

Re: this used to be my bag..

I think your problem is that you fear change. I'm going to send you on a course to deal with that.

[Not Yb]

Re: this used to be my bag..

First you'll need to, read "Who moved my cheese?" favorite book of "Management by diktat" types everywhere.

[Pickle Rick]

Re: this used to be my bag..

And then there are politicians...

[abend0c4]

Re: this used to be my bag..

they were porting a mainframe app (cobol/cisc/jcl etc) to Java

There's an even more fundamental point here - why were they even attempting it in the first place? There are plenty of solutions for running CICS/COBOL on other hardware and normally that would be a preferred option for "legacy" software that's poorly documented but continues to work. It will almost always be cheaper to bring in an expensive specialist to fix the code from time to time than to rewrite the whole lot in a way that replicates the original in all its documented and undocumented behaviour - particularly in the likely event that there is poor test coverage.

There's an assumption that a "modern" implementation will be easier to maintain. However, if you take poorly-understood legacy code and further obfuscate it by translating it literally into a language with fundamentally different concepts you in fact make maintenance even more difficult. You may more easily find someone who understands the programming language but you make it immeasurably harder to understand the program.

I fully agree that you need to validate your assumptions at an early stage in the project, but too many assumptions get a pass simply on the basis of zeitgeist.

[Paul 76]

Re: this used to be my bag..

Actually did this once ; well I came in just after it started. Property Management vertical app written in this sort of psuedo-assembler-floating-point language, ran under CP/M. They wanted to run it on IBM PC hardware, so it was line by line converted to 'C'. It mostly worked, but the customers who had all bought new PCs got a product that was actually slower ...

Even then as a young lad I'd probably have rewritten the pseudo assembler, would have been much easier and more reliable, and you could extend it (theoretically)

[David Hicklin]

Re: this used to be my bag..

it will never happen, the code is just too big and they would have to put a code freeze in place whilst they did it - and they can't go years without changing something!

[Claude Yeller]

Death March

Almost all efforts to write a project from scratch or into a new, completely different language fail. Most of these rewrite projects disappeared.

The value of a code base is totally in their tested and debugged code. It is the testing and debugging that creates the value.

Any new code will require the same decades of testing and debugging the old code received. Not feasible in 4 years.

And "AI" is used here in the way "self correcting ink" was used in Harry Potter. People see AI as a kind of Genie in a bottle that will fullfil their wishes. But neither magic spells nor genies exist in the real world.

[Concrete Gannet]

Re: Death March

Joel Spolsky wrote about the disastrous three year gap between Netscape 4 and 6 because they tried to do a rewrite.

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

It's probably not a good idea.

[Not Yb]

Re: Death March

That was definitely a large cause of the eventual death of Netscape as a for-profit company, but don't forget the other 'we'll bundle our browser FREE' proximate cause of death.

[Will Godfrey]

Re: Death March

The project that I work with had a fatal bug in it that took over 10 years for any user to actually hit. It took a long time to find it, but the fix was trivial.

[Pickle Rick]

Re: Death March

> But neither magic spells nor genies exist in the real world.

That's why as a 50+ y/o virgin I have all my wishes granted by unicorns!

[Mine's the one with the vial of liquid psilocybin in the pocket!]

[Bebu sa Ware]

Re: Death March

"People see AI as a kind of Genie in a bottle that will fullfil their wishes."

Perhaps they should read The Brass Bottle by F. Anstey 1900 to see how well that worked out.

[bazza]

Re: Death March

Rust came in to being specifically to support a re-write of Firefox from C++ to Rust! And, they've done a fair bit of that now.

Indeed, the value is in tested, known-to-work code. However, a code re-write in a language that is at a higher level than the original does make sense, and has been done comparatively often. The higher level in theory means that there's less testing / debug to do, and that can be essential for a piece of software to expand so as to help the overall testing burden of such an expansion to remain manageable.

This is precisely why compilers were written in the first place; if not, we'd all still be using assembler.

[renke]

Re: Death March

> Our North Star is ‘1 engineer, 1 month, 1 million lines of code.’

The whole premise is dead in the water, when the "north star" actually means that a human stays in the loop.

Even with the murderous 996 work schedule this requires doing a review of the LLM output at a rate of around 55 LoC per *minute* (assuming 25 work days per month on average, with 12 hours each).

The worst kind of task you can ask someone to do: Boring as fuck AND requiring high concentration.

Even this back-of-the-envelope calculation clearly shows that the approach is not working: Not sustainable and the error rate will go up. As this should be also clear for the guy posting this on linkedin I assume that MS does not actually wants to hire a Principal Software Engineer (able to actually do the code review) but a sloperator (willing to play the scapegoat when [not if] the LLM produces crap, not noticed before it is already pushed to production).

[Lusty]

I’m reading this as the start of vastly increased salary/consultancy rates for skilled C and C++ devs. This happens any time you “kill off” a computer thing. COBOL, anything IBM original, Netware, all have niche and in demand skills and C will be no different. I’ve even seen some pretty desperate asks for Delphi.

[volsano]

The beauty of starting a new project is that it has no known problems - thus making it a zillion times better that all existing projects that have many known problems.

New projects with no known problems are like steroid catnip to managers and investers.

If Microsoft can speed up the process of replacing existing projects with new ones, they will drive down their known problems list to zero.

Profit!

They just need to remember that all new projects will be replaced by newer projects at least once a week.

[bazza]

I know someone (younger than myself) who deliberately launched themselves off into COBOL. They're very busy and successful.

[Pete 2]

Won't get fooled again

> replace its entire C and C++ codebase

Meet the new bugs, same as the old bugs.

Maybe not in principle, but the same as far as user inconvenience goes.

[stiine]

Re: Won't get fooled again

Ah, but some of the bugs in Microsoft code are currently deemed to generate correct output.

[Pickle Rick]

Re: Won't get fooled again

MS Hack #1: Aw nuts, that's not the output I was expecting that code to return...

MS Hack #2: Yeah, but look, it's actually correct!

MS Hack #1: I'm a genius!

Nascent Dev: And I am eternally grateful we're heterogeneous.

[blu3b3rry]

"It's new and shiny - it must be better!"

This smells rather strongly of bonus-chasing manglement and/or trying to find yet another justification to shareholders for all the money they've spaffed on AI crap.

Sometimes new and shiny is nice, but this definitely isn't one of those times.

[Anonymous Coward]

Re: "It's new and shiny - it must be better!"

I agree with your reasoning, Microsoft jumping to Rust does smell a lot like bandwagon bullshit...but I don't get the hate for Rust here.

C/C++ were once "the new shiny", and I'll bet that was originally deemed to be shit and was irrationally hated by a lot of folks...everything was new and shiny once...

Do you expect every new thing to somehow have decades of heritage on release?

I've coded on and off with C/C++ for 20 years...it's the one language that I return to that I kid myself into thinking that I like, then after a few hours I find a whole new reason to hate it...particularly plain old C.

In the last couple of years I've been learning and building things in Rust and it hasn't once pissed me off...it's actually really nice to code with and the compiler is extremely straight forward to debug...I have yet to experience a compiler issue that is just a generic segfault type affair...along the lines of "Error: [Done] ... exited with code=0"...really crappy debug output on C/C++ alone brings my piss to a boil. It's almost always due to a third party library that itself has errors in it...so you spend more time debugging someone elses code to get your fucking code to work...which is when you find out you're using a fork of a fork of a fork of a library...so you track back to the original library and find it hasn't been updated in 13 years and from that one repo there are possibly hundreds of forks all with tweaks and updates for very specific purposes...it can be a nightmare...this is particularly annoying if you're working on an inherited codebase...because not only are you using a whacky fork of a library from a dead repo...you probably don't have any documentation or record that explains why that specific fork was used...

I've inherited a few Rust codebases and I've not once had this issue...

Whether Rust actually is better than C/C++, I don't know...I just know it's a lot nicer to work with...can't really comment on performance etc...because it usually doesn't matter for the kind of projects I tend to work on, and both C/C++ and Rust seem to be comparible performance wise, put it this way, I've never noticed Rust apps to be slower or C/C++ apps to be noticeably faster...but what I will say is that I've ported more Python or PHP projects to Rust than C/C++...and there you do get a rather significant performance jump (particularly against Python, PHP not so much) and a large reduction in complexity in a lot of cases (again, particularly with Python).

I ported one Python project which was fucking huge (well to my standards anyway), had hundreds of files and tens of thousands of lines of code plus a huge amount of dependency baggage...I ported all the functionality to Rust and got it down to about 10 files, hardly any dependency baggage and around 3,000 lines of code...deployment of this solution is now a single binary rather than a fuck ton of guff followed by an hour or so of pip commands, pyenv backflips and other associated bullshit.

I personally see Rust as a better alternative to server side scripting than I see it as a replacement for C/C++...I can code just as quickly in Rust as I can in PHP (PHP being the language I've spend the most time in, approx 27 years) and I can ship a single binary (or several if I want cross platform compatibility).

Rust is a very chill language to code in...which is why I draw parallels with PHP, because PHP is incredibly chill...C/C++ and Python are definitely not chill...especially Python.

As for vibe coding with Rust...I don't do a lot of vibe coding (if any), feels like it creates more work for me...at the very least, generating a ton of code then spending hours checking it is a lot more boring than writing it yourself...I can see the appeal for people that either don't have a lot of experience coding or just aren't very good at it...because vibe coding can take you places that you otherwise might be able to reach but for me, spending a day checking robot code for errors feels like more work than 3 days just writing the code myself...if vibe coding was less "chunky" in the way it worked (as in, offered more fine control over code production, akin to "stepping through") then it might be more interesting and more viable as an option for me, but for now it sucks all the fun out of coding for me and I don't feel like it actually speeds me up. Most of the speed up you get from vibe coding is as a result of not checking/reviewing the code I think and just "trusting" it...which is a bit silly if you ask me.

[Doctor Syntax]

Re: "It's new and shiny - it must be better!"

".but I don't get the hate for Rust here."

I don't see any. What I see is extreme scepticism in Microsoft's belief in it as a magic bullet.

[Anonymous Coward]

Re: "It's new and shiny - it must be better!"

"new and shiny"

That is typically derogatory around these parts, used as a subtle dig at new tech by people that shout at their shoes. Often used to imply that a technology is pointless.

Rust is not "the new shiny" it actually has merits and is a worthwhile technology. I don't see it as a direct replacement for C/C++ but rather a better tool for doing things that C/C++ maybe isn't very good at and was never really designed for.

As techies we need to stop looking at "new shiny" as direct replacements for things, we should be looking at new things as extra tools in our toolkits. Everything can be fixed with a hammer, just not very well...sometimes we need tools that do things well.

[blu3b3rry]

Re: "It's new and shiny - it must be better!"

Indeed, no hate for Rust here, more distaste and cynicism for the slapdash way Microsoft seem to want to implement it.

I'm no programmer, but from what I've gleaned by reading up on it a little it certainly has advantages over other languages.

However I don't expect any exec making these decisions at Microsoft to have knowledge beyond "is new so better plus justifies AI".

[Anonymous Coward]

Re: "It's new and shiny - it must be better!"

You wouldn't think it with all the venom around here over Rust making its way in to the Linux kernel...and there is general distaste for "new shiny" round here...almost everything in recent years that is new has been shat on quite heavily in these forums.

Systemd...nope!

Wayland...nope!

Rust in the Linux Kernel...nope!

AI...nooooooooooooooooooooooope!

Blockchain....fuck nooooooooooooooooooo!

Windows 11...nope!

It's difficult to determine what would pass as an acceptable new technology around these parts...if anything.

I can't think of a single thing that these forums has generally approved of that is actually new that isn't a reimagining / relaunch of a dead tech.

This place doesn't bite the hand that feeds IT anymore, it shills the hands that are familiar to IT.

[Anonymous Coward]

Re: "It's new and shiny - it must be better!"

You're missing the point. All technology has problems, specially NEW technology.

Wanting people not to break their existing car wheels in favor of using quantum dots in a matrix of electron foam is being sensible.

All of the things you've mentioned (like ALL tech) have problems. Pointing out the problems, and choosing to use something else, isn't shilling. There's a reason they frequently call the new shiny, "bleeding edge technology".

Besides that, I don't think many people here understood what you meant by "shills the hands that are familiar to IT" anyway. That's a very odd, and to me, totally meaningless, turn of phrase.

[Anonymous Coward]

Re: "It's new and shiny - it must be better!"

I agree...but technologies like systemd, wayland, rust etc...these are not bleeding edge...they're over a decade old, they didn't come out of nowhere. The technologies down the line that might eventually step in to replace these technologies likely already exist in obscure repos somewhere in a barely usable state in an early concept phase...they're likely just side projects for now.

I totally see why people might be sceptical of AI, blockchain etc...they haven't been around long enough to establish long term effectiveness or even usefulness...before AI and blockchain, there was no older version of AI and blockchain...they are literally cutting edge tech...most stuff exists in existing segments...display protocols, init systems, programming langues...they were designed with reasons in mind, usually to provide some kind of functionality or optimisation that didn't previously exist in existing solutions...they usually come about because they fix long standing problems that were not going to be fixed in existing solutions or couldn't be fixed. They have a reason to exist. If problems didn't exist in existing solutions, they wouldn't exist at all...if X11 was amazing, Wayland wouldn't exist...if previous init systems didn't have drawbacks, systemd wouldnt exist...if C/C++ didn't have it's inherent problems, Rust wouldn't exist etc etc...there's no point in hating things like this simply because they're relatively new.

[Anonymous Coward]

Re: "It's new and shiny - it must be better!"

Again, everything has problems. RC-style init and xwindows have been around for 60 and 70 years. By that standard, a mere 10 years is not well tested.

Unfortunately there are many people who seem to think that they MUST evangelize the new just because they love it. It's not hate to dislike being told what to use. I have no hate for systemd or wayland, I'd just rather not use them at this point.

[Paul 76]

Re: "It's new and shiny - it must be better!"

Changing the colour scheme does not a new operating system make ...

[Anonymous Coward]

Re: "It's new and shiny - it must be better!"

I meant the bigger picture...as in these forums in general.

[DrXym]

Re: "It's new and shiny - it must be better!"

It's also worth mentioning, this is one guy saying his goal is this, not Microsoft's.

But even if it were Microsoft's, the real issue isn't whether Rust is safer than C (it obviously is) but whether it's worth rewriting existing code for the sake of it. I could entirely see the point of writing new code in Rust but not necessarily some ancient Win32 DLL which hasn't been a vulnerability for as anyone can remember.

[bazza]

Re: "It's new and shiny - it must be better!"

The GNU coreutils seem to have benefitted from a re-write in Rust (fewer bugs including some that were discovered along the way, quicker).

Rust's sneaky party trick is that you don't have to really decide. If you've got a big pile of C (e.g. a kernel) and you want to add a new module, you can write that module in Rust and have a proper calling interface with the existing C. You can do the re-write at leisure.

Though one of the aspects that worries me is that one might end up with a bunch of Rust modules calling each other as if they were C (probably much use of the Unsafe keyword), whereas if the whole code base was pure Rust you'd not have that.

Interfaces are something that most software / software ecosystems does very badly. The worst is command line interfaces; fine if used by a human in an intended way on a terminal, but absolutely terrible as a means to get data moved from one program calling into another. We need fewer ways of interfacing. Anyway, my point is that just because a code base has been converted from one language to another, that's not necessarily the end of it. Getting rid of the old way of interfacing modules and adopting the new language's way is an essential part of the task.

[stiine]

Re: "It's new and shiny - it must be better!"

Really? I've read that what you describe is only true if the existing interface will rust, otherwise the interface in rust has to be built to a c spec.

[Anonymous Coward]

Re: "It's new and shiny - it must be better!"

"whether it's worth rewriting existing code"

Is it worth mowing your lawn if it's just going to grow back?

When you swap languages it isn't necessarily about fixing existing problems, it's sometimes about removing potential barriers in the future, or opening up the codebase to fresh developers, breathing new life into something etc etc.

When you're a company like Microsoft, you've probably had the same devs going round in circles bouncing around the other large companies for decades...the only way out of this doom cycle to bring in fresh eyes and a new perspective is to change languages to capture fresh eyes and new ways of thinking.

Not all technical decisions are made for technical reasons. Some technical decisions are made to change paths, open up new possibilities, to crack a window and let the funk out when the space starts to stink.

[MikeTheHill]

Assumes it's possible

The thing about memory safety is that you cannot design programs or libraries without adhering to those constraints.

But what about programs and libraries written in C/C++ that don't follow those constraints? Changing such code to conform to constraints may require a complete redesign along with a change to its signature. The ripple effect of this is likely enormous.

For those of you who have written C++, do you recall the first time you tried to change a function variable to a const? You can easily end up going down a very long rabbit hole with hundreds of changes propagating up and down the dependency tree. Now try changing 10,000 variables to const and see how long it takes you to untangle that mess.

The thing is, once you go down the conformance path there is no way to do the conversion piecemeal. One day all the programmers will be writing in C/++ and next day they'll all be writing in Rust with a code base that they will probably barely recognise. Good times.

[stiine]

Re: Assumes it's possible

Maybe I read a different article. The one I read seemed to indicate that there would only be rusty AI programmers during the conversion, and only AI afterwards.

[Paul 76]

Re: Assumes it's possible

Rust is designed with safety in mind isn't it (I've never coded in it), so it is designed to avoid jiggery pokery.

I vaguely seem to recall it doesn't allow NULL pointers as such but handles them as some sort of exception type mechanism.

I don't see how that's going to translate if the code it is coming from relies on NULL pointers. I mean , it's possible to convert it, but it sounds like a disaster waiting to happen.

[tater]

As I predicted

I said years ago AI will move the goal posts. Projects unattainable in the past will become attainable.

[Pickle Rick]

Re: As I predicted

Absolutely correct. Until now there have been no projects to correct the reams of LLM slop heading our way. The joy of a brave new world beckons - I think I'll pass TYVM.

[Anonymous Coward]

Re: As I predicted

You mean, people will see how crap the AI generated results are, BUT will also see that people are actually happy to spend ludicrous sums in the hope of getting ways to, say, convert C/C++ into goood idiomatic Rust that they'll finally fund a project to do that *properly*, startiing with properly defined compiler tools... The Big Programming projects really ought to have been done by now.

[bitwise]

Frangipani insane

One engineer, 1 million lines a month.

Well thats incredibly stupid, there is no way they can understand what they are doing.

The rule some open source has that contributors must understand what they commit is a solid one.

Absolutely reckless of microsoft to gamble the company like this.

[bazza]

Re: Frangipani insane

To be fair, I think that even MS hold this to be an aspiration. I mean, if it was one engineer, 1 million lines a month *done well* that'd be a heck of an accomplishment. 1000 lines per day may be realistic, for fairly basic code. I very much doubt that they're actually going to churn through 1 million lines of code per engineer per month and ship the result regardless...

What I think is interesting is that, now, Rust appears to be the way of the future for MS. Are they the first major house to declare such an "all-in" on Rust? Makes me wonder what this'll do to the wider industry. Will Rust get ISO standardised? If Windows makes the transition and starts seeing real reductions in CVEs as a result, would the Linux kernel project start thinking about wider adoption? Who knows?

The US gov has been making strong noises about software getting written in safe languages. That might get more prescriptive if there's a major OS that has been re-written. Linux is a big deal now in server land, but if Uncle Sam starts insisting on its business being conducted on Windows because it's been rewritten in a memory safe language (national security, etc), that could put the cat amongst the pigeons.

[stiine]

Re: Frangipani insane

Why would you think they'd have to understand the new Rust code? After all, they'll be using AI to generate it.

[Vader]

Not going to happen. They will fuck it up.

[ecofeco]

It's M$. Of course they will. Sure as the sun rises.

[Repne Scasb]

A million lines of slop

Goodhart's Law is alive and well. LOC are no indicator of quality, reliablity, functionality, usability or suitability. Oh, wait, Microsoft, I think I see the problem here.

[Bran Muffin]

Sorry, I have to laugh a little

Who uses Microsoft's products? I don't know, but they do it to the tune of 100 billion dollars in profit for fiscal 2025...

[SarahC_]

So basically:

We're back to the slower automatic bounds checking C++ programmers used to avoid like the plague because their skills made sure they checked the out of bounds hacks.

Then lesser coders came, and we got printf and the rest without bounds checking... so, so hackable.

Capitalism sure leads to ensh----cation!

[that one in the corner]

> Then lesser coders came, and we got printf and the rest

Um, printf() is one of The Original C Standard Library Functions (see K&R 1st edition). The lack of type data that any variadic C routine suffers from (and C+ necessarily inherited) is one of Life's Great Blunders, from our lofty perspective, but back then...

Stopping your incoming lesser coders from adding new printf()s into your existing code is always a problem, but you can get ahead of them by

#define printf PrintF

Int PrintF(const string& str, const P& p1 = P::Nowt(), const P& p2 = P::Nowt(),

and fill in as many p1, p2 ... p100 as you feel the need for. Define class P appropriately to deal with all the standard types etc etc, you know the drill.

[Anonymous Coward]

AI and Algorithms?

"AI" is algorithms, or as I like to call it "Algorithmic Interpretation".

[kmorwath]

Microsoft should improve its recruting procedures...

.... it's clear it onboarded a lot of clueless people following only Fashion Driven Develpment (FaDD) rules - and the current management can't understand it because sees only profits.

It will be especially funny to see how they could rewrite object-oriented C++ code into a non-object oriented language - AI or non AI. Unwindig inheritance and polymorphism coud led IMHO to a lot of AI-generated spaghetti code that could be unmanteinable.

[that one in the corner]

Re: Microsoft should improve its recruting procedures...

> rewrite object-oriented C++ code into a non-object oriented language

You get a copy of cfront (i.e. the original implementation of C++, with all the object-orientation but a bit lacking in the template department) and use that to compile the C++ into plain old C.

cfront may(!) need a tweak to the grammar it accepts, but overall that is a doable thing and the output wasn't spaghetti. Lots of weird names for temporaries and you will see the unvarnished mangled names, but once you get the hang of the mangling algorithm...

[kmorwath]

Re: Microsoft should improve its recruting procedures...

A lot of time and and a lot of changes have been made from the first implentation of C++ - and any OO language. Do you believe an old, simple implementation could still work?

Of course OO code is no longer OO when compiled. But still an OO compiler knows how to implement inheritance and polimorphism. It's no surpirse that recent languages like Go and Rust aren't OO, for the simple reason that writing an OO compiler is far more complex, and exceptions handing as well. So get rid of them so you're able to write is, since you don't have the skills of previous developers. I've seen many developers unable to graps OO - so no surprise the new ones preferred to avoid it - and tha''s why I don't like Rust. It could be more memory safe than C (that is an ugly language badly developed) - but it still makes simple things far more complex than they should be.

How do you handle C++ exceptions in Rust? Good luck...

[that one in the corner]

Re: Microsoft should improve its recruting procedures...

> A lot of time and and a lot of changes have been made from the first implentation of C++. Do you believe an old, simple implementation could still work?

(NOTE I have cut out "and any OO language" from that quote, and will say why soon)

Yes. For "modern" C++, yes, I definitely do believe "an old, simple implementation could still work" because, ta-da, it DOES! The VMT is still there. What do you believe has changed?

For "any OOPL" - yup; the other OOP mechanisms still work. Why would message-passing, the other Great OOP Way, have broken? Please provide some examples, 'cos I am *always* happy to learn about programming language internals (preferably not just more irritants caused by ambiguous syntax, 'cos that is important to let people write unambiguous code but isn't really novel, just overly complex sticking plaster over features that just growed).

> for the simple reason that writing an OO compiler is far more complex

No, it really isn't. Templates are *much* harder to get right than C++ style statically bound objects, and polymorphism is just syntactic sugar, not much harder than other sugar like the "for" loop. Injecting constructor/destructor calls needed a tweak to the linker, to handle initialisation of static instances (for early compilers).

Exception handling is a separate issue - it interacts with destructor invocations because it needs to have an unwind stack for the exception handler to walk. Getting the kinks out of the mechanisms took work for the C++ guys to get right *BUT* that has all been sorted out and the mechanisms published - including how it had problems interacting with iritants that arise from the fact C++ still supports C'isms that let you bypass the proper stuff.

> How do you handle C++ exceptions in Rust

Is there something especial in C++ exceptions, compared to other languages that provide exceptions? Ada, etc? Or do you feel that *any* exceptions mechanism is going to break Rust's memory ownership properties? If Rust *wanted* exceptions, it could have them. BUT would that be a good idea?

The choice to avoid exceptions in Rust was, to my understanding, that although languages like Ada provided them to "be good for critical military applications" experience with, bluntly, C++ code in the wild, demonstrates that that just ain't the case. The fact that any sane person could think that having a hash table trip an exception when it doesn't contain a key, instead of returning a null/false/nope entry makes it abundantly clear that milspec code must be kept exception-free.

Yes, obviously, translating C++ code that insists on using exceptions as a means of implementing the application logic into a language without exceptions is decidely non-trivial. As in, the only sensible way to do it is to clean up the C++ first. Which, if you want to use a machine to do the translation, means you need that as a clean-up first, before any attempt at translation. And that clean-up probably invilves getting in some really good human programmers. And probably means the translation, done well, is probably too expensive. But that won't stop idiots flinging LLMs at the problem, which will fail.

> I've seen many developers unable to graps OO

I'd put the lack of OOP being built directly into other languages onto that - people not wanting it, not grokkking it - more than fundamental difficulty of implementation. Assuming (yes, yes, big assumption) that, when you start your new language, you begin by learning *how* to implement a language, from lexers onwards, then statically-linked OOP is all well-defined, pros and cons. Just RTFM.

[that one in the corner]

Re: Microsoft should improve its recruting procedures...

Should let this go, but I re-read this thread and realised that I'd skated over this gem:

> Of course OO code is no longer OO when compiled

WHAT?

The compiled code is still OO after it has been compiled!

When - and how - could it suddenly lose its objects?

The ONLY difference between the same program's code in Assembler[1] and code in C++, or code in C versus C++ when considering cfront, is that the C++ has *supported* writing using objects: it has done some housekeeping for you, removing the need for you to manually write the boring bits. A bit of pseudo-C++

class L { ... }; class F { virtual DoStuff(class L *l) { ... } }; class Fred : F { virtual DoStuff(class L *l) { ... }}; class Lucy : L { ... }; class Jim : Doris, Lucy { ... }; Fred fred; Jim jim;

that leads to invoking a method

fred->DoStuff(jim);

is no more or less "object oriented" than the possible pseudo-C code that a pseudo-cfront may generate

fred->_FredVmt->Fred__DoStuffArity1classL(fred, Lucy__LucyAsaclassL(Jim__JimAsaclassLucy(jim)))

and neither are any more or less "object oriented" than the final assembler (no, I'm not going to write out the pseudo-Asm code here, that would far too long and boring - and prone to a ludicrous number of typos on this touchscreen!)

The C++ is just(!) a lot easier to get right - because the language is *supporting* the use of the OO idiom, whereas when all the support sugar is expanded out it becomes painful for a human to remember what the necessary fiddly bits are; much easier all around to let a program (i.e. pseudo-cfront) remember that jim used multiple inheritance so you *have* to call its "as a" converter (as it stands, you *could* get away without the call to the second "as a" converter, but removing that is an optimisation stage!). The pseudo-C form is able to do all the clever stuff the pseudo-C++ does, invoking the overridden virtual method etc; assuming, that is, you have remembered to manually declare and define the structs holding the VMTs. Whilst the pseudo-C++ coder just let the compiler support him by filling in those easy-but-tedious-to-fill blanks for him.

To argue against this continuance of objectness in the compiled form is as daft as arguing that assembler code can not be calling functions, just because it exposes the magic behind the C-style concept of a function call (namely, pushing arguments onto the stack, before doing the GOSUB and then carefully popping them off again).

[1] let's use the Assembler - not Macro Assembler, no cheating - code, rather than binary, simply 'cos we can accept that Assembler is human-readable and can still carry information in names and comments, aside from which it is 1:1 equivalent to the binary that is actually executed.

[that one in the corner]

Re: Microsoft should improve its recruting procedures...

PS

Don't forget, if the LLM has been fed with everything they can scrape from the web, that includes the output from cfront *and* all the "how to implement OOP in plain C" (plain Fortran, plain Pascal - actually, no, plain Pascal can't and TurboPascal already had it): OOP goes back to the 1960's (and earlier, less codified) after all.

So if an LLM can produce *any* code, it is as likely to produce text based on (copying) proper "implement an object" code as it is to try to "invent" its own spaghettified method of doing it. Unless you think that there is a mass of home-grown "I tried to implement objects but totally messed it up - and put that onto Github" that will outweigh the older, decent, stuff and is therefore more likely to be spat out by the statistical "people who coded that also coded this" LLM generator.

[Anonymous Coward]

Re: Microsoft should improve its recruting procedures...

I believe the (still theoretical) rewrite is 'translate existing source code into Rust", not "translate this compiler-generated C equivalent of the C++ source code into Rust". One of those ideas is much harder to get right (for humans), and I think it's the second one that's harder for AI as well.

Other than as a technical aside, I'm not sure what cfront has to do with any of this, really. This is a management problem masquerading as a new AI process.

[frankvw]

The horror, the horror...

Microsoft, a complete code base replacement from C/C++ to Rust, and AI, all in one fell swoop.

What could possibly go wrong? <shudder>

[jetjet]

Bill G waking up in the morning, reading social medias, sipping coffee and said: "Look ma' Linux is going to Rust. Let me call my code monkeys to do the same."

[Fara82Light]

Bugs

I think this is a bad idea. Microsoft Developers would have to work twice as hr to maintain their quota of bug introduction code!

[Fara82Light]

Effort

Don't waste your effort on rewrites; just put it all in the bin.

[JoeCool]

Roadmap clarity

I really do appreciate MS putting transparency on their future directions.

That certainly does help buttress technology decisions currently being mulled ...

[nijam]

> "Our strategy is to combine AI and Algorithms to rewrite Microsoft’s largest codebases"

As if their codebase weren't bad enough already.

[Anonymous Coward]

Pick your P45 up as you leave through the front door

This seems likely to arrive at the point where the OS code is only maintainable by AI. Source code that works like a dream but is so fiendishly complex that it is nigh on impossible for mere humans to comprehend how it works, let alone determine why it went wrong: something like the highly optimised assembly/machine code generated by modern compilers.

What a great time to be an OS developer :(

[jmsgwd]

Not all new projects

> The CTO of the company’s Azure cloud called Rust to become the default language for new projects”.

The linked article does not say that. It says all new projects that would otherwise be written in C/C++. Systems programming, in other words. And likely a small fraction of new projects.

[davoy]

Totally misleading headline, but the press jumping on it anyway.

While there are no doubt initiatives to move more stuff to rust, this is a statement of one research-guy at MS pushing his AI Agenda, not a company goal.

Apart from that:

- Most C++ bashing coming from people who have obviously no clue

- C and C++ are (for the sake of this discussion) different languages

- Almost all MS code relevant for this discussion is in C

[E 2]

Visual Studio

As of Visual Studio 2022, no Rust.

Is it available in the latest VS?

[ForthIsNotDead]

This will be written about for years...

... as the moment that bankrupted Microsoft.

[Boris the Cockroach]

Re: This will be written about for years...

We can only hope

[Penguinista]

I'm sorry...

...but I'm not sure I can take anyone who calls themselves a ‘Distinguished Engineer’ very seriously, especially when it comes from someone who works at Microsoft.

Maybe he means ‘Extinguished Engineer’ due to the way Microsoft is pushing its AI ringpiece (Copilot) into all its products and operations?

[Anonymous Coward]

There have been 100 replies to this article, and NOT A SINGLE ONE of them is positive of the claims or of this endeavor at all.

How do managers even come up with this stuff? What can they base it on?? How does anyone ever believe them, instead of fire them on the spot???

[Penguinista]

“How do managers even come up with this stuff?”

They probably get it from ChatGPT.

[Pirate Peter]

"They probably get it from ChatGPT."

don't you men "Co-Pilot"

[Anonymous Coward]

Nah.

Copilot was made agentic in the last few months, so it can invoke web APUs etc, and it now just passes all the hard work over to ChatGPT and just takes all the credit.

Hmm, does that remind you of any Microsoft management?

[Jou (Mxyzptlk)]

Microsoft never hid that Copilot is a product using ChatGPT as engine. There is no "takes all the credit".

[Not Yb]

For very small values of "never", I'd say. There's no obvious indication of "powered by ChatGPT/OpenAI/etc." in the Copilot interface that I can see.

I tried asking it "What LLM are you based on?", and it says "I’m Copilot, created by Microsoft, and I’m built on the latest cutting‑edge large language models from across the industry. I don’t have access to the specific model name, architecture, training data, or size. My job is to focus on what I can do for you, not what’s under the hood."

"Do you use ChatGPT?" got an outright denial: 'Not directly. I don’t “use” ChatGPT, and I’m not a ChatGPT instance wrapped in a different name.'

That's a pretty strong indication that they actively hide the actual LLM used from the average user.

[Ken Hagan]

"That's a pretty strong indication that they actively hide the actual LLM used from the average user."

Er, no. It's a pretty good example of how LLMs can't be trusted with even the most basic levels of factual accuracy.

[Ascy]

My Calculator Says...

My calculator says that if this mythical engineer is working 20 days per month and 8 hours per day, then they will be each and every one of those hours reviewing 6,250 lines of code. So either they have done incredible performance enhancing drugs at Microsoft, or they plan on just hand waving unreviewed AI code through into production. As a very experienced software engineer who uses AI a lot, I can say with complete confidence that putting AI code straight into production without looking it over is going to not end well for Microsoft.

Or more likely, the person who came up with the North Star quote is actually from Microsoft's marketing department and hasn't figured out how to use a calculator.

[Jou (Mxyzptlk)]

Re: My Calculator Says...

Or

they

are

paid

by

lines

written.

It

is

easy

to

write

code

vertically.

Compilers

don't

care.

My

solar

control

script

would

jump

from

~1600

lines

to

probably

64000

lines.

Without

comments

of

course.

And

no

empty

lines

(

Alt+255

anyone?

)

[Mike VandeVelde]

Re: My Calculator Says...

You introduce money into the eqation, and gameification immediately ensues. Who cares about security on this intranetted internet of universities and scholars doing what they love? But you put any profit into any of it and all of a sudden EVERY EDGE CASE GETS FULLY EXPORED. You want how many "lines of code" to remain employed?? OK hold my beer watch this. One million pshaw, give me a bonus and I can make it two or ten million no problem.

[that one in the corner]

Re: My Calculator Says...

Loop unrolling FTW.

[[e-mail]]

C/C++ are vastly superior to Rust for many things.

It is illogical to replace C/C++ with a language like Rust that is not as powerful or flexible. The only problem with C/C++ is when programmers forget to initialize pointers and check their validity before referencing them. That just requires better programming habits to fix. Rust buys you nothing and adds needless complexity.

[Claude Yeller]

Re: humans can write secure C/C++

"The only problem with C/C++ is when programmers forget to initialize pointers and check their validity before referencing them."

Please, supply us with evidence humans can write memory safe C/C++ code?

Because, your description of programmer's errors is simply a description of "humans".

[Petalium]

Have them fix the mess that is settings in Windows first….

[Phil995511]

An operating system generated by AI, how awful, help, ban it !!!

[Pirate Peter]

sound like they used their own ROI calculator

as per the title

it sounds like someone asked their AI generated ROI calculator how long to rewrite the windows code base using AI tools

and they got the answer which as normal is as realistic as a unicorn prancing through their office

mind you it depends what they have been smoking they may well have seen said unicorn in their office :)

[Andrew Williams]

Well, there's this...

It seems to be that the rust rewrites going on in the Linux world seem to have one thing in common... that the coders are reaching for the "unsafe" option.

So, what to make of that? Is some stuff just not doable in a "safe" style? Or is it more to do with the coder?

Given the size of the Windows codebase,, well... are they going to take a lot of time and effort to recreate a different mess?

[tygrus.au]

Windows should become a GUI on top of Linux

Windows should become a GUI on top of Linux.

[Anonymous Coward]

Re: Windows should become a GUI on top of Linux

Just need to move around a few things, make the NT Posix layer primary, instead of the NT Win32 layer, slide it all gently into a merge with WSL.

> Windows should become a GUI on top of Linux

Maybe that has been the plan all along, ever since they gave up on the Halloween Email attitude.

[Jou (Mxyzptlk)]

Re: Windows should become a GUI on top of Linux

> Windows should become a GUI on top of Linux.

NOOO000ooo!!! The GUI is the part where Windows 11 sucks and where the performance gets eaten away! And you propose to put that on top of Linux and expect it to be faster? It won't.

[tyrfing]

Isn't this what killed Netscape? Rewriting the code base?

Microsoft must be feeling really complacent if this is what's being pushed. No competition at all.

[JavaJester]

Rust in Visual Studio?

Does Microsoft have any plans to fully support Rust as a first-class language in Visual Studio Proper (not just Visual Studio Code)?

[[e-mail]]

Yet another AI marketing stunt.

I am sure that no one at Microsoft honestly expects to sell an operating system created this way. They are hoping that some IT managers will say "Hey, if Microsoft is willing to rewrite Windows using AI then surely we can rewrite our line of business applications that way. Let's pay Microsoft for Copilot!"

[Pickle Rick]

Re: Yet another AI marketing stunt.

> I am sure that no one at Microsoft honestly expects to sell an operating system created this way.

You appear to be imbuing M$ with ethical standards as yet unseen.

[davoy]

Lol, Microsoft just called the guy back:

https://www.windowslatest.com/2025/12/24/microsoft-denies-rewriting-windows-11-using-ai-after-an-employees-one-engineer-one-month-one-million-code-post-on-linkedin-causes-outrage/

[Henry Wertz 1]

What I would do...

Having used C, C++, and Rust (I prefer Python myself, but even there you end up with a fair number of addons that wrap a C implementation of it), you can have simple C code where you replace the #include lines with mod or !include equivalents, and it's one for one the same. It's really like using C with "maximum paranoid" compiler flags (that error out on anything questionable) and like a paranoid Lint that runs at compile-time, with restrictions on pointer usage and other things that lead to memory use errors.

If I were converting C code to Rust, I would first write some code that handles simple cases, and flags code it can't handle automatically. Handle more of those cases. Find the ones it can't handle and handle more. There will be some cases where the code is doing something questionable, a human will have to intervene and fix something up (or you can give the AI a go and see if it helps out). If you want to use AI to iterate this code development so be it, but you then end up with an actual toolchain tool that converts one code to another predictably, versus an AI where you might give it the same task twice and get different results.

Doing an actual code review would be better, but I think converting 'simple' code with a tool and then manually reviewing the rest you could get through many lines of code without just having an AI like Vibe code it for you (with the inevitable unpredictable results.)

[powershift]

bs

total bullshit. nfw would they take every driver and convert the language. Its too much work for nothing. They aren't that stupid so the story is miss-leading.

[StrangerHereMyself]

Good idea

I personally believe this is a good idea. The job of transpiling / translating code from one programming language to another is mostly grunt work: it requires some inteligence but not much and A.I. is perfectly suited for this.

It's comparable to the Y2K code modifications we did a quarter of a century ago.

How many COBOL codebases are still running because transpiling them to a modern language is simply too costly and risky? With .A.I. the job could be done in weeks or even days.

[Pickle Rick]

Re: Good idea

Either you're suggesting the LLM generated code would be shipped "as is" or you're omitting the review and testing part. Dry running all of that code would be mind destroying[1].

> How many COBOL codebases are still running because transpiling them to a modern language is simply too costly and risky? With .A.I. ....

... you're introducing a whole new class of risk. The mitigation of which would be avoided by not going there in the first place. Being realistic, a human's going to be involved in the _programming_ cycle at some point[2]. With LLMs the human is undertaking program logic sanity checks _after_ coding rather than before, and that seems arse about face to me.

[1] Don't tell me, an "AI" could do that!

[2] Granted, I may have wandered from the path taken by some $Corps.

[StrangerHereMyself]

Re: Good idea

No, the tranpiling to another language is just the grunt part. After that software engineers need to partially rewrite and test the code to verify it functions and to change the architecture to suite their needs. It's only the start of a process where there's a large human input and effort needed to be able to put the software into production.

The job of transpiling is done is a few days. The job of engineering the software to be ready for use takes much much longer. But this route makes it feasible when it previously wasn't.

[Anonymous Coward]

Who Put "RUST" in "TRUST"?

See title!

[Flywheel]

You mean .. actual .. humans?

> and is hiring people to make it happen.

Hard to believe I'm reading that!

Anyway, the vision of an AI vibe-coded version of Windows 13 fills me with dread, how are mere mortals going to afford 1Tb RAM? The CPU heat will compensate for the lack of heating in winter though.

[LBJsPNS]

I am going to have to order more popcorn.

[C R Mudgeon]

Buzzword overload

I instinctively distrust people who talk like that guy. The same buzzword four times in three paragraphs. Yeesh!

I can just picture the Hunt household yesterday morning: "Merry Christmas, kids, at scale".