Microsoft To Replace All C/C++ Code With Rust By 2030 (thurrott.com)
- Reference: 0180441903
- News link: https://developers.slashdot.org/story/25/12/23/010200/microsoft-to-replace-all-cc-code-with-rust-by-2030
- Source link: https://www.thurrott.com/dev/330980/microsoft-to-replace-all-c-c-code-with-rust-by-2030
Hunt says he's looking to hire a Principal Software Engineer to help with this effort. "The purpose of this Principal Software Engineer role is to help us evolve and augment our infrastructure to enable translating Microsoft's largest C and C++ systems to Rust," writes Hunt. "A critical requirement for this role is experience building production quality systems-level code in Rust -- preferably at least 3 years of experience writing systems-level code in Rust. Compiler, database, or OS implementation experience is highly desired. While compiler implementation experience is not required to apply, the willingness to acquire that experience in our team is required."
[1] https://www.thurrott.com/dev/330980/microsoft-to-replace-all-c-c-code-with-rust-by-2030
[2] https://www.linkedin.com/posts/galenh_principal-software-engineer-coreai-microsoft-activity-7407863239289729024-WTzf/
Hahaha (Score:2)
They are going to do this in an automated way, meaning the bugs will be copied too as "features".
Re: (Score:2)
Let's hope so. In old code bases you can't always just fix every bug because many bugs have through use and abuse evolved to be considered part of the contract. An AI assisted rewrite that did not migrate known bugs would likely be a grand failure.
Re: Hahaha (Score:2)
APIs are often buggy. Sometimes, you really need to use them for your project. If you choose not to call those APIs, and there is no suitable replacement, your project will also not get done. You may lose your job as well as a result. There is no good choice.
Good luck getting the OS fixed if Microsoft is the vendor. And if they do, they may break many other apps that are distributed in binary form, that had to work around the API bugs previously.
Oftentimes, when binary compatibility is a concern, the compro
Re: Hahaha (Score:2)
It's a very old codebase.
They probably are retired.
But MS was all about using undocumented shot for the purpose of stating ahead of their competition that was stuck with documented features.
Re: Literally? (Score:2)
Well not figuratively, so I'd say yes.
Reminds me of an EDA tool version 9 (Score:2)
A long time ago, in a galaxy far far away, we used an EDA tool whose much touted release 9 was long delayed and when it arrived was buggier than an insectarium on steroids.
Some years later I met the team lead of that release. It was because management had mandated a complete rewrite into C++. I also learned that the CFO loved that release because revenue from maintenance contracts went up. For years.
I will watch Microsoft's future progress with considerable interest.
Re: (Score:2)
This is were "if it is not broken, do not fix it" comes from. Although, to be fair, MS code is pretty broken. AI use will just make that worse.
I guess they could jettison their steaming pile and hire all the Wine devs for a "rewrite", but I doubt they have the vision or insight for that.
Sounds great (Score:3)
Rust is incredibly powerful. And it makes a lot of sense for software companies to embrace it. On the other hand, any projects that aren't actively maintained will bitrot very quickly. Rust gets a new stable release every 6 weeks, and deprecating features that aren't working out or are superseded is a normal part of the process.
In comparison, I could pick some ISO/ANSI release of C and have it supported by native tools for decades. Picking C89 or C99 as a baseline, nearly every C compiler supports it now. Aiming for C11 or C17 for better 64-bit and Unicode support still gives you the possibility to support your application on a wide range of toolchains and runtimes. It is entirely possible that C isn't sufficient for your project, at least bare bones ISO C. You're often on the hook to maintain your own platform specific extensions. These might be pretty small for a command-line utility or back-end service like a relational database. Or platform specific libraries may be a huge pain in the neck like in game development.
Re: (Score:2)
Can you clarify about released features being deprecated? I've read rust RFCs and they're always going on about how some feature is unstable (and in Nightly rust only) because it's not finalized and they can't change it after it's marked stable. AFAIK if you use Rust 2024, you will always be able to compile as Rust 2024.
I like the nightly features, but they're usually to save a few lines of code or not need to write an extra helper function. Nightly features aren't need for serious software or libraries.
Re: (Score:2)
The Rust standard library (std) currently guarantees multiple compilers in the same application so crates buildable on stable will always be buildable. Therefor std can't really fully deprecate API.
If Rust 1 (there will be no "2") then any bit of Rust code for stable should still build in the future. It has been demonstrated before that a program built against rust 1.0.0 can still be built. But what is left out that "experiment" is that team will all move to a newer version of Rust rather than keep multiple
Do not take that job (Score:3)
I worked at Microsoft for over a decade, and only had one bad performance review. That was after a partner team decided not to support the feature that my feature depended on. Since my feature didn't ship, and since somebody had to be at the bottom of the stack rack, I was my manager's logical choice. He got burned too, for he same reason.
(At the time, I just thought "welp, I guess it be that way" but I'm hindsight it pisses me off the more I think about it. I busted my ass to hold up my end of the project, and was ready to go until the other team pulled the rug out from under us. My manager left MS a couple months later, and I probably should have too. But I did make senior a couple years later, so no real harm done.)
Anyway....
If AI is fundamentally not good enough to convert a million lines of code per dev, the principal engineer they're about to hire is going to be the logical choice for their manager's bottom-of-the-stack.
That's a high risk. AI is not what executives think it is.
Re: (Score:2)
> That's a high risk. AI is not what executives think it is.
Indeed. But this job is actually low risk as in low-uncertainty. You are assured to fail, no chance in hell for this to go differently.
Sure. (Score:3)
Take a large code base that works fine now, with the occasional memory overrun, and make massive changes to it. "Works fine" will become a distant memory.
Re: (Score:1)
"works fine" -ish?
Re: (Score:2)
Yep. That's the flag they're going to use: -ish
Re: (Score:2)
hey, but this is scalable algorithmics at scale!
> Our algorithmic infrastructure creates a scalable graph over source code at scale.
Re: Sure. (Score:2)
Joel still very much relevant:
[1]https://www.joelonsoftware.com... [joelonsoftware.com]
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
Re: (Score:2)
Yep, first thing I thought of was Joel's diatribe against rewriting your codebase from scratch.
Re: Sure. (Score:2)
Surely, nothing that another lot of updated licence agreements can't cover.
Works 99.9% of the time.
Re: (Score:2)
Works fine? No. Works somewhat under good conditions? More like it.
On the other hand, MS has now failed numerous times to implement "WinFS", so maybe they will just end up wasting vast amounts of money with no results.
Re: Sure. (Score:2)
But at least it will be a distant memory-safe
Re: (Score:2)
> Take a large code base that works fine now, with the occasional memory overrun, and make massive changes to it. "Works fine" will become a distant memory.
There are two reasons why the 1980s thought process of "change your passwords frequently" is no longer advised:
1} Users will revolt and end up doing stuff like "password1", "password2", or writing it on a sticky note.
2} If a password is compromised, it should be changed immediately , not in 90 days, and if it's not compromised it shouldn't be changed, because of #1.
Rewriting the entire codebase when the vast, vast, vast majority of it has an insane number of people-hours testing it and vetting it is ins
Re: (Score:2)
NIST SP 800-63 has formalized this. Specifically, look up Section 3.1.1.2 in SP 800-63B-4, released just this year. Minimum length 15, max length at least 64, but no other requirements, including complexity or regular rotation. Unicode is supposed to be accepted, normalized against a standard process (that one I don't remember, but it's documented), with one code point counting as one character. Filtering for known bad passwords or patterns is strongly encouraged.
I pushed through an implementation at our co
How does that saying go? (Score:1)
Aim for the stars, be happy with the moom, but don't be surprised if you get lost in space.
Okay, I added that last bit, but it seems so appropriate here.
let's watch (Score:2)
I was going to post "If it ain't broke, don't fix it." but this is microsoft we're talking about. Their codebase is pretty broken already, so, let them have at it. I'll watch the chaos with firefox on linux. I just hope my bank and the financial markets don't crash too hard if it gets that bad.There's a lot of dependence on MS products.
AI and Rust are the current hotness (Score:2)
So it's only natural that Microsoft embraces the both of them. Maybe they can put the code "on the blockchain" while they are at it *laughing emoji*. Oh sorry that's so 2021
But taking my cynical hat off, it's not the worst idea I've heard. Zuck's "metaverse" and Tim Cook's iCar have been far worse IMHO. This could actually result in something useful. A lot of Windows code could probably do with a refactoring, and be made less x86 dependant. I think this will have positive flow-on effects for Open Source.
1 engineer, 1 month, 1 million lines of code,... (Score:2)
... and 1 million bugs. If I worked at MS now, I'd be looking for a new gig last week.
Re: (Score:2)
Why? There's sure to be plenty of work fixing the inevitable bugs this project generates.
What can go wrong... (Score:2)
Nothing, actually. Windows is already a stinking pile of shit. Can't get any worse.
Re: (Score:2)
You are an incurable optimist. Things can *always* get worse.
Re: (Score:2)
I agree. But if they break it completely and then cannot back out (would not surprise me if that happens), this world may finally get rid of Microsoft and we can have some progress in the mainstream OS area again instead of the steps backwards MS is making these days. (Yep, since the downgrade from Win10 to Win11, I have found numerous new ways to crash Windows, drivers, etc.)
hiring, huh (Score:2)
"Hunt says he's looking to hire a Principal Software Engineer to help with this effort."
if there's one thing my career is lacking, it's working for a "distinguished engineer" who can say with a straight face that he plans to port 30+ years of source code from an unsafe to a safe language using fairy dust and slop generators
Re: (Score:2)
To be fair, you can probably cross-compile C to Rust, if you make the target "unsafe" and disregard performance.
C++? I do not think so. Rust has a very non-standard and limited OO model. Good for systems coding, not good for porting C++ to it.
Re: (Score:2)
Well, you can (or used to be able to) translate C++ to C, and presumably go from there to Rust, but the resulting code will basically be non-human-modifiable.
Re: (Score:2)
Pretty sure the existing Windows code is already non-human-modifiable, otherwise they would've fixed the bugs by now.
Re: (Score:2)
Well, true. But you end up with unmaintainable code. To be fair, most Microsoft code will be unmaintainable at this time. On the other hand, up to now, they could at least patch gross security problems, probably with high effort. Using a C++ -> C -> Rust compile-to chain, I do not see that being possible anymore in the target code.
Dilbert lives! (Score:1)
I once got to port part of DirectX to an experimental managed language. The original code was extraordinarily crufty, and the problems were endless. Rust is at least as big a change, even if it does feature some level of safety checking. And they get to use AI!
I wish I still had contacts to follow this story. I don't think it will be public for very long.
Exceptions (Score:2)
Except for the stuff that they can't get the AI to convert for them. So, you know, all the stuff that barely holds together in Windows and Office, full of iterated pointers.
AI-assisted, large-scale refactoring.... (Score:4, Informative)
I think that may be what will finally kill them. Good.
Having confidence in one's own products (Score:3)
You got to give it to 'em.
C-Suite, How hard could it be? (Score:3)
CoPilot re write all Microsoft C/C++ code in Rust. There! done!
Re: (Score:2)
> Microsoft seems to be doing these kinds of migrations lately.
I think their old ways of poorly documenting things even internally came back to bite them. I've seen some things written by people who were at one time Microsoft devs working on Windows 7, 8, and 10, who said that a lot of removed functionality came because trying to figure out what the old code was supposed to be doing was nigh impossible, and figuring it out sometimes just didn't fit the schedules or budgets. If a feature didn't seem to be wide
Who said it would be easy? (Score:2)
Or bug-free? A rewrite would of course ben an interesting and ugly process. A couple of years in debug/fix alone.
But we are regularly assured Microsoft code is crap, it's buggy, and it's terrible. The only questions are:
- Is Microsoft code as bad as claimed?
- Would it be worse when they are 'done', as if software is ever 'done'.
I'll get some popcorn laid aside. And I'll hopefully get to see and use the fruits.
I've worked at my job almost 20 years (Score:1)
Worked with 3 or 4 big codebases* and written two myself. I think I've just barely crossed the million LoC mark if I add all that together.
It doesn't quite pass the laugh test that a single dev can supervise (I have any meaningful level of responsibility for delivering) that many LoC per month, even if he's got a thousand monkeys at a thousand terminals hanging on his every word, especially when almost all of the Windows and Microsoft products code handles oddball corner cases like hardware interfacing.
Micr
Re: I've worked at my job almost 20 years (Score:1)
*big codebase: at least 200kLoC and written over at least three years or by at least three people.
History repeats itself... (Score:2)
History repeats itself...Microsoft is repeating the mistake that Netscape made during the browser wars. As examined: [1]https://airfocus.com/blog/why-... [airfocus.com]
One of their former Microsofties, Joel Spolsky, warned about this... [2]https://www.joelonsoftware.com... [joelonsoftware.com]
Microsoft will do the rewrite, and then suddenly decide for reasons, to go back to the old source code...And Rust gives the promise of memory security, efficiency, but there was another language that had that facade, Java. Professional managers and the hype o
[1] https://airfocus.com/blog/why-did-netscape-fail/
[2] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
Windows 12 (Score:2)
Windows 12 is going to be hilarious!
Yay. (Score:2)
I love it when Microsoft shoots itself in the foot.
What could possibly go wrong? (Score:5, Insightful)
I'm not a software guy, and even I know this has a very high probability of failing miserably.
Re: (Score:3)
On the other hand, Microsoft trying to write an OS in Rust will reveal absolutely every defect present in the language.
Unless they write their own, which is quite likely as they'd rather have defects they can ignore.
Re: (Score:3)
Not really. My guess is they will not really make their way out of "unsafe" and hence win absolutely nothing in that rewrite. And C++? I am not even sure you can port that to Rust without essentially writing a compiler that adds all the missing OO features. Rust has limited and very non-standard OO. Which makes sense given its aims, but not when you come from C++.
Re: (Score:2)
> Not really. My guess is they will not really make their way out of "unsafe" and hence win absolutely nothing in that rewrite.
Let's assume for a second that this is true, and they have to literally encapsulate the entire thing in unsafe (which is absurd as this repeatedly made claim by C++ developers is total bullshit, but let's go with that for argument's sake.) Unsafe rust is still a HELL of a lot more safe than C++. Among other things, RAII is still enforced, whereas with C++ not only is it optional, most C++ developers are very bad at sticking to it even when they try. Unsafe rust still provides type safety, temporal safety, a
Re: What could possibly go wrong? (Score:3, Insightful)
I am a Software guy, and can confirm that so much will go wrong.
Re: (Score:3)
What's the worst thing that can happen? A different-colored blue screen?
Re: What could possibly go wrong? (Score:2)
Everything is going to go wrong.
Re: (Score:3)
> Everything is going to go wrong.
Their top guy [1]Murphy [wikipedia.org] is heading up the re-write. :-)
[1] https://en.wikipedia.org/wiki/Murphy's_law
Re: What could possibly go wrong? (Score:1)
Well we have a consensus that the basement masturbators think it will go wrong. What would you retards do if you didnâ(TM)t have microsoft to cry about?
Re: What could possibly go wrong? (Score:3)
I've done migrations. Not on this scale, but big. The problem isn't the 1-to-1 stuff; the problem is all the edge cases. All the stuff that only worked because it made bad assumptions that happened to work out in context. This is going to expose a lot of bugs, and that's good, but fixing those bugs will in some cases be a huge problem.
Re: (Score:2)
Given the features being added to Windows lately, I think failing to run is the best possible outcome.