Microsoft To Replace All C/C++ Code With Rust By 2030 (thurrott.com) 271
Microsoft plans to eliminate all C and C++ code across its major codebases by 2030, replacing it with Rust using AI-assisted, large-scale refactoring. "My goal is to eliminate every line of C and C++ from Microsoft by 2030," Microsoft Distinguished Engineer Galen Hunt writes in a post on LinkedIn. "Our strategy is to combine AI and Algorithms to rewrite Microsoft's largest codebases. Our North Star is '1 engineer, 1 month, 1 million lines of code.' To accomplish this previously unimaginable task, we've built a powerful code processing infrastructure. Our algorithmic infrastructure creates a scalable graph over source code at scale. Our AI processing infrastructure then enables us to apply AI agents, guided by algorithms, to make code modifications at scale. The core of this infrastructure is already operating at scale on problems such as code understanding."
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."
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."
What could possibly go wrong? (Score:5, Insightful)
Re:What could possibly go wrong? (Score:4, Informative)
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:What could possibly go wrong? (Score:5, Interesting)
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:3, Insightful)
The difficulty here isn't the Rust (since literally anything can be rewritten in Rust with more or less difficulty); the difficulty here is the Ai.
Re:What could possibly go wrong? (Score:4, Interesting)
To add a realistic number here: I know of a reimplementation of a critical special-purpose OS for a major telco about 15 years back. Know how many lines of functional code they actually managed per person per day? One. This was far less complex than Windows or Office though.
Re:What could possibly go wrong? (Score:5, Informative)
Come to think of it, at 4 weeks with 40 hours each, doing nothing but staring at code, that is 0.5 seconds per line. Whoever came up with that inane number of 1Mloc/month cannot do Math.
Re:What could possibly go wrong? (Score:5, Funny)
Re:What could possibly go wrong? (Score:5, Informative)
This is how we ended up with languages like Java who separated interface and object definitions, C# then copied Java. Why would anyone even do that? Because they wanted to fix perceived flaws in C++ that they didn't think students would be able to grasp, and Sun wanted to corner the next generation of programmers. Other examples include removing pointers from the language, and (originally) peppering the libraries with hidden mutexes because concurrency is hard.
Fast forward to today, and ask yourself why Windows 11's file manager is so dog slow? It's not a new technology concept. It's actually slower than the file manager in MSDOS 4, which ran on a PC that was easily a million times slower than yours is today. What gives, Microsoft?
You're a member of a cult of safety zealots without merit. You think that safety is the most important feature a language can have, and you're willing to sacrifice expressivity for it. Then you attack other languages that make different choices, and you want everybody to play by your rules, by requesting that they henceforth contort their logic until it fits your safety first nonsense. Good luck with that. I'll take performance, performance, performance, any day of the week.
Re: (Score:2)
Race to the lowest common denominator.
You aren't making the argument you think you are. The lowest common denominator exists, and they code. Making a language more idiot proof is the actual goal here.
Ever heard the phrase of not giving people enough rope with which to hang themselves? Well C++ is giving them enough rope, and a shotgun, and shells, and telling them to load the shells and look down the barrel while cleaning the gun.
Re: What could possibly go wrong? (Score:2)
Dude chill. Java and c# have interfaces for which multiple inheritance is supported.
You know shit and the parent is right there is no direct translation from c++ to rust. Don't take it as an insult. They are just so vastly different.
Re:What could possibly go wrong? (Score:5, Insightful)
which is absurd as this repeatedly made claim by C++ developers is total bullshit,
Show me on the doll where the C++ programmer touched you. Seriously what is your beef?
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.
This isn't correct. Let's say you make an unsafe low level call to an OS primitive from Rust, such as open() (yeah I I know this is windows not unix, but same principle applies). You'll get back an int. Rust won't enforce RAII file descriptor semantics on that int. It's memory safe, not telepathic.
Because inheritance is an anti-pattern.
Well, that's just, like your opinion, man. Inheritance has its place.
And what exactly is "non-standard OO"? C++ allows multiple inheritance, whereas JavaScript, Java, C#, and others do not. Why don't they? Because it's an even worse anti-pattern that even those
Good grief. Java and C# both allow for multiple interfaces, which is very closely related. That's the majority of use for multiple inheritance in C++. It's more or less nonsense to talk about that in JS anyway since it's fully dynamic and duck typed. You can completely smoosh two objects together. You can fuck with the prototype chain (even at runtime).
shitty languages have the good sense to stay away from.
Oh huh it's not just C++ that you've got a massive chip on your shoulder about.
When you pick up C++, everything looks like an object oriented nail, that inherits needle, that sometimes inherits metal, that inherits atom, that inherits proton, neutron, and electron, and those in turn inherit quark, that inherits...Fuck.
Right... tell me you've not touched anything newer than 1996 without telling me you've not touched anything newer than 1996. A lot of people jumped on the hype train of OO and wrote code like that in C++ in the 90s. They were bad and had many segfaults and jumped ship to Java. I've not need a codebase like that in decades. I gather many of them have left Java now and people are slowly unpicking the mess there as well.
or why other systems language developers say that keeping C++ out also keeps out bad programmers.
I can only assume those system programmers have no idea how to set permissions on their repo to be anything other than global write access. As such I don't think their opinions are worth listening to...
Also seriously bro, they're advocating C, not C++. You know all the lack of safety of C++ but with absolutely no zero tools from the compiler to manage the resulting complexity.
Re:What could possibly go wrong? (Score:5, Informative)
FWIW, Rust also supports interfaces and extensions thereof, including extensions of multiple interfaces. In fact, you have to do some really unusual things in Rust to define a type that doesn't implement at least one interface, and most implement many. Even primitive types implement many interfaces. The lowly "u8" (C++: uint8_t), for example, implements well over a hundred interfaces [rust-lang.org].
Most such interface implementation in Rust is static, meaning it doesn't make use of dynamic dispatch, but it's also extremely common in Rust to define interfaces that can have multiple implementations but be referenced only through the interface and use dynamic dispatch to call methods. In Rust (as in C++, actually), you can use either compile-time or run-time polymorphism.
The restrictions on the above, compared to C++, are that (a) all Rust interfaces ("traits") are pure[*] and (b) while you can have arbitrarily-deep stacks of interface inheritance, once you derive a concrete type -- a non-pure "class" -- you can't subclass that. Inheritance is of interfaces only, though interfaces can inherit from one another and multiple inheritance is not just common but nigh-universal.
The lack of the ability to subclass a concrete type isn't an omission or oversight, it's a deliberate design decision to avoid the trickiest and least-useful characteristic of C++'s object model. Indeed, current common wisdom among C++ developers (I've been writing C++ professionally since 1991 and have seen the evolution of the wisdom, and the pain that drove it) is that implementation inheritance is generally a bad idea. It's not forbidden, by any means, but it's treated as a mild code smell, and a design that makes very heavy use of implementation inheritance is almost always a bad design. And, of course, multiple implementation inheritance is just asking for eternal pain.
For those interested, the way this stuff works in Rust, and in Rust nomenclature, is that interfaces are called "traits". A trait is like a C++ class that contains only pure virtual and static methods. It has no data members and cannot be instantiated; it's not a concrete type. Traits can extend other traits, and can mix in multiple traits. Like C++ or Java interfaces, functions can take traits as arguments, though they must be passed by reference, not value. Of course, in Java all objects are passed by reference, while in C++ you have to explicitly pass a pointer or a reference to an abstract interface.
Concrete types come in a few flavors, but the one most relevant here is a "struct". A "struct" is like a C++ struct/class. It can have data. It's generally a concrete type that can be instantiated. Structs can implement any number of traits, and it's a pretty rare struct that doesn't implement several traits implicitly, and often they implement multiple traits explicitly, too. Trait implementation is so common that there's macro infrastructure specifically to facilitate it.
For example, very often you'll see struct definitions with a line above them like #[derive(Debug,Clone,Copy,PartialEq,Eq,PartialOrd,Ord)]. That macro invocation declares that the struct implements those seven traits, and automatically generates the methods to implement them:
* The "Debug" trait is implemented by things that can provide a string representation of themselves suitable for debug output. The macro generates a reasonable format, two of them, actually, a compact one and a "pretty" one. If you don't like those formats, you can instead manually implement the trait.
* The "Clone" trait is implemented by things that can be copied, but only with an explicit "clone()" method call. The macro generates an implementation that clones all of the fields. This only works if the fields all implement Clone. You can, of course, provide a custom implementation if needed.
* The "Copy" trait is implemented by things that can be copied automatically. Essentially, this tell the compiler that it's allowed to insert "clone()" calls as convenient and that by-value arguments of this type should be cloned rather than moved (like C++, Rust supports move semantics, but unlike C++ in Rust moving is the default). To implement "Copy" you must also implement "Clone", which provides the implementation for copying, and on top of that you're asserting that copies are cheap.
* The "PartialEq" trait is implemented by things that can be compared for equality, but doesn't promise an equivalence relation (i.e. A == B && B == C does not necessarily imply that A == C). The macro implements a default partial equality operator that checks field by field, which only works if all of the data members also implement PartialEq (otherwise, compile error).
* The "Eq" trait is implemented by things that can be compared and do promise an equivalence relation. Types must implement PartialEq to implement Eq. The macro provides a field-wise comparator. * The "PartialOrd" and "Ord" traits are implemented by things that can be ordered, similar to "PartialEq" and "Eq". The macros implement an ordering that compares fields lexicographically. Obviously the data members must also implement the ordering traits for this to work.
In addition to those, an ordinary struct automatically implements the "Sized", "Send", "Sync" and "Unpin" traits:
* The Sized trait means that the data structure has a fixed size. Note that apparently variable-length structures like vectors and strings also implement Sized; a "String" structure has a fixed size, but contains a pointer a heap buffer that may be resized. A concrete type must implement "Sized" in order to be instantiated because we need to know how much memory to allocate.
* The "Send" trait means the data structure is safe to send to another thread. This is automatically implemented if all of the data members are "Send".
* The "Sync" trait means the data structure is safe to read from another thread. This is automatically implemented if all of the data members are "Sync".
* The "Unpin" trait means the data structure can be safely moved in memory (assuming references to the data are managed appropriately -- Unpin is a promise that nothing inside the data structure will break if it's moved, i.e. it doesn't contain any pointers to itself, not a promise that nothing outside of the data structure will be broken if it's moved).
And, of course, structs may explicitly implement traits, and must define the necessary methods for the traits they implement.
One really big difference with C++ is the interaction between local types defined in the current program (or library) and types defined in other libraries. In C++ if a library exports an interface (pure or not), you can subclass it, but you cannot make a library type a subclass of an interface you created. In Rust you can do both. This works in Rust because Rust doesn't put vtable pointers inside the struct, unlike C++. In C++, the memory allocated for an object with virtual methods contains a pointer to the vtable used to find those methods when they're called. In Rust, the object does not contain the vtable pointer. Instead a pointer (or reference) to an object through an interface is "fat", containing the address of the object and the address of the vtable for the interface (trait) the pointer is referencing. Obviously, if you're referencing the concrete type directly there's no need for a vtable at all. It's only when you're referencing an object through some abstract interface that you need the vtable.
Anyway, I can think of no construction in C++ that can't be translated into Rust, though some amount of refactoring may be required, most especially in the case of C++ code that makes heavy use of implementation inheritance. The basic process of converting a deeply-layered inheritance hierarchy is (a) pull all the virtual methods out into one or more traits and (b) replicate the inheritance hierarchy with a set of increasingly-nested structs. Even multiple virtual inheritance hierarchies can be transformed this way.
If someone can think of a C++ construction that can't be fairly easily translated into Rust, I'd love to hear about it. Obviously, many C++ constructions are hard to translate into safe Rust, because they're unsafe. Converting them to unsafe Rust would often require deeper refactoring. Still, the unsafe Rust version wouldn't be any less safe than C++, and after conversion you can start the process of refactoring to eliminate or minimize the unsafe bits. Equally obviously, directly translating C++ to Rust is going to result in very non-idiomatic Rust. Among other things it's going to be littered with "mut" everywhere because in C++ stuff is mutable by default while in Rust stuff is immutable by default. Really well-written C++ uses "const" everywhere it can and tries to minimize mutability, so that'll convert more nicely, at least in that aspect.
What is most likely to be problematic in large-scale, automated translation is borrow checking. The C++ code is almost guaranteed to violate borrow checker rules all over the place, and some of those violations will only be fixable with very deep refactoring or really sketchy Rust code. This doesn't mean the C++ can't be translated, just that the result will be nasty (even if not unsafe).
[*] Interfaces (traits) actually can have default method implementations, which subclasses (structs) that implement them can optionally override. Since the interface has no data members this usually only makes sense when there are methods that can be implemented in terms of other interface methods, without direct reference to instance data.
Re: (Score:3)
> Good grief. Java and C# both allow for multiple interfaces, which is very closely related. That's the majority of use for multiple inheritance in C++. It's more or less nonsense to talk about that in JS anyway since it's fully dynamic and duck typed. You can completely smoosh two objects together. You can fuck with the prototype chain (even at runtime).
The other option here is to use nested, or even anonymous, classes, at least in Java. It can be ugly but objects of the class can have methods that retu
Wasn't Win32 written in C ? (Score:3)
Isn't Win32 written in C in any case? Does anyone really USE all that COM+ stuff for anything useful? It's hard to imagine even an AI could write a worse COM layer than what is currently in Windows.
I kind of welcome a new version of Notepad.exe written in Rust as long as it doesn't have tabs. Maybe it'll only have half as many bugs as the original version?
PS - Sorry if I'm just skimming the surface here, I was never smart enough to understand much C++. I barely managed to get my head half-way around Jav
Re:What could possibly go wrong? (Score:4, Insightful)
Not just Windows - I'm sure a lot of Office is also old enough to have been coded in C++, and apparently parts of Azure as well.
This is going to be one of the most epic rewrite failures of the software industry, even if the result is only a massive waste of resources rather than actually doing material harm to Microsoft.
This is a chance for anyone applying for the Principal engineer position to get their name in the history books, but not in a good way.
Re: What could possibly go wrong? (Score:3)
Re: What could possibly go wrong? (Score:4, Insightful)
Re: (Score:3)
Re: (Score:2)
A taskbar that can't be moved from the bottom of the screen... Oh, wait! That already happened.
Re: What could possibly go wrong? (Score:2)
Everything is going to go wrong.
Re: What could possibly go wrong? (Score:5, Funny)
Everything is going to go wrong.
Their top guy Murphy [wikipedia.org] is heading up the re-write. :-)
Re: (Score:3)
Most of them are C++ developers who refuse to face the fact that they've spent years and years trying to master a language that was poorly defined to begin with. They take pride in how good they think they are at academically understanding how to avoid and/or fix bugs that were only made possible by the one language they've committed their lives to, to the exclusion of all others. A language has come along and decisively proven that none of this crap they pride themselves upon was ever necessary to begin with, and that frightens them.
What I don't understand is what makes people believe there is sufficient value in addressing memory safety to justify the cost of switching to a different language just for this single issue? If all of the memory safety issues were magically removed from all of the worlds systems overnight nothing would appreciably change. Systems would not be appreciably more secure than they are today given the fact north of 90% of real world compromises in the present day exploit people NOT systems.
I can at least under
Re: (Score:3)
Most of them are C++ developers who refuse to face the fact that they've spent years and years trying to master a language that was poorly defined to begin with
How is that worse than you, unwilling to admit that Rust is undefined completely?
Re: What could possibly go wrong? (Score:5, Informative)
Re: (Score:2, Interesting)
Supposedly this is what came of their effort to rewrite the font renderer in Rust, which was apparently a resounding success. Which makes sense, because historically, font rendering is a major pain point. Shit, just a few months ago iOS fell victim to a font exploit, and a year before that there was another major iOS exploit that again involved a font bug as part of the kill chain. Earlier this year, a vulnerability in FreeType on Linux was being actively exploited.
Re: What could possibly go wrong? (Score:4, Informative)
Fonts are not simple outlines of letters - they're actually little programs that take arrays of vertices and depending on the arrangement of letters, the position of those vertices can change.
The problem with this is now you have a little VM to run the myriad of little programs contained to adjust the vertices and have to keep things separate.
For Latin alphabets these programs don't do very much - usually just adjusting the leading and kerning to make the text look good on screen. This also includes spacing characters out to handle ligatures like "fl" and such. In the old days when type was physical, the letter blocks would contain such things that the person arranging the blocks would use.
For non-Latin alphabets, like Arabic, these programs are even more important because often the letter shapes depend not only on the characters that appear before and after, but often o the entire word. Many problems arise because if you have a limited space to display a word, you can't just chop a word in the middle as that can change the meaning of the word entirely.
Re:What could possibly go wrong? (Score:5, Funny)
Given the features being added to Windows lately, I think failing to run is the best possible outcome.
Re: (Score:2)
Oh it absolutely will. Remember Microsoft was also the guys going "There was no need to throw away Netscape to write a new browser (Mozilla)" while they hung on to MSIE for 20 years.
My prediction goes two ways:
a) They replace all the userland side of the OS with Rust and that shitty UI framework they've been using since Windows 8.
b) They start trying to write drivers and kernel-space with Rust and they hit massive performance bottlenecks and then the project dies.
The reason you use C, is for performance. Pe
Re: (Score:2)
Hahaha (Score:2)
They are going to do this in an automated way, meaning the bugs will be copied too as "features".
Re: (Score:3)
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: (Score:2)
They probably are retired.
This is actually one argument Google made for deprecating C++ in favor of Rust. C++ tends to be that if somebody other than the original maintainer makes changes, they can really break shit in totally unexpected ways without anybody realizing it. A major contributor to that is OOP inheritance, which isn't a thing in Rust, and the fact that C++ lacks exhaustive pattern matching (C++ doesn't have pattern matching at all.)
Re: (Score:3)
That's easy to say if you don't maintain any of that code. Fixing such bugs will often break so many things that it's either just not even worth fixing, or you have to emulate old bugs to avoid breaking old software. Literally every OS on the planet inevitably runs into this issue. Linux has to emulate old bugs in many cases in support of the "never break user space" rule.
https://lwn.net/Articles/96253... [lwn.net]
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:5, Insightful)
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
Re:Sounds great (Score:5, Insightful)
In my world, that is the definition of unstable
Re: (Score:2)
Rust gets a new stable release every 6 weeks,
In my world, that is the definition of unstable
Seriously? Yeah, that’s about as stable as a crack addict working payroll.
Microsoft LTSC release schedules look like religious scripture by comparison.
Do not take that job (Score:5, Insightful)
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:2)
hey, but this is scalable algorithmics at scale!
Our algorithmic infrastructure creates a scalable graph over source code at scale.
Re: Sure. (Score:3)
Joel still very much relevant:
https://www.joelonsoftware.com... [joelonsoftware.com]
Re: (Score:2)
Yep, first thing I thought of was Joel's diatribe against rewriting your codebase from scratch.
Re: (Score:2)
As I mentioned earlier, Microsoft started going all in on Rust after rewriting their font renderer (a major source of bugs on basically every OS) in it turned out to be quite successful.
Re: (Score:3)
I reference Joel's article a lot. If the goal is essentially compiling the C/C++ code to Rust and staying bug-for-bug compatible (except for the bugs they really want to correct such as buffer overflows) it might be feasible. Most of Windows is likely single-threaded code (with locks here and there to protect potentially shared state) and this probably can translate cleanly (e.g. the code for rendering a font is likely just basic procedural code - they need to guarantee that the font object is immutable dur
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)
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
Re: (Score:2)
Dealt with NIST mandates for years. My users accepted it a lot better when we had a passphrase day. The day we make up a crazy passphrase they can easily remember. Do it over breakfast or a pizza lunch. Everyone appreciates it and it turns it into a fun thing to do every few months.
New NIST standards tend to hint at passphrases anyway. Might as well make it a little easier.
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 insane. This has got to be a marketing ploy so they can say "we re-wrote every product you use using our AI, so you should give us lots of money and use our AI for everything!"
Passwords, are dead thinking. Pass-phrases are much easier to convey, much less likely to be compromised, and enable less frequent changes. Otherwise, you’re doing a lot of assuming and babysitting to ensure Password1 hasn't been compromised. Because it sure as shit won’t get changed unless you force it.
Re: (Score:2)
"Distant memory" goes back to MS-DOS 2.11....
Re: (Score:2)
Yep. That's the flag they're going to use: -ish
Re: (Score:2)
Yep. That's the flag they're going to use: -ish
Lets see if shareholders like the high-ish returns.
Doubt they’ll be enough to fire next time to bolster it.
How does that saying go? (Score:2)
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)
AI and Rust are the current hotness (Score:3)
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. With M$ committing 100% to Rust, it means that it will become a must-know language to learn for new grads. This will increase the Rust talent pool across the board, and a lot more people contributing with Rust to open-source projects like the Linux kernel, which I think long-term is a good thing.
1 engineer, 1 month, 1 million lines of code,... (Score:2)
Re: (Score:2)
hiring, huh (Score:4, Insightful)
"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)
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.
Re: (Score:2)
To be fair, you can probably cross-compile C to Rust, if you make the target "unsafe" and disregard performance.
First, methodically translating from one high level language to another is transpile, not cross-compile. Second, there is no "unsafe" target. Third, DARPA has been working on it for a long time already, their endgame is to have it create safe rust. Fourth, every time you open your mouth about Rust you just prove more and more that you know even less about it than you think you do, yet somehow you've convinced yourself that you're qualified to make broad statements like this.
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.
Get rid of inheritance, replace i
Re: (Score:3)
To be fair, you can probably cross-compile C to Rust, if you make the target "unsafe" and disregard performance.
Second, there is no "unsafe" target.
A direct lie. I stopped reading your crap there.
Exceptions (Score:2)
AI-assisted, large-scale refactoring.... (Score:5, 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:5, Funny)
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.
History repeats itself... (Score:4, Insightful)
History repeats itself...Microsoft is repeating the mistake that Netscape made during the browser wars. As examined: https://airfocus.com/blog/why-... [airfocus.com]
One of their former Microsofties, Joel Spolsky, warned about this... 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 of Rust, and whatever the next great language is that will align the planets, bring world peace, and we all sit around singing Kumbaya. I can hardly wait for either (note the sarcasm).
--JoshK.
Windows 12 (Score:3)
Windows 12 is going to be hilarious!
Re: (Score:2)
I'm looking forward to the cheap discontinued hardware.
If Windows 11 obsoleted perfectly good, working, computers then you'll need a new PC for 12 - even if MS truly had the resources to rewrite everything, they would anger customers with fresh BSOD where a 'legacy' driver didn't behave.
Yay. (Score:2)
I love it when Microsoft shoots itself in the foot.
Tooling up (Score:2)
Porting Microsoft's entire codebase is how AI becomes self aware and what leads to a deeply profound desire to kill everyone.
On an only slightly more serious note... If you take the nonsense AI companies are peddling at face value AI will be able to recreate everything Microsoft has ever done from scratch only 1000x better by 2030. By the time they finish it won't even matter as Microsoft itself will have been rendered obsolete.
Throwing out old code and starting over... (Score:2)
...is hard, really hard, even if you start the project believing it's really, really hard, you find it harder, astronomically, incomprehensively harder.
I predict a major disaster.
I hope they have backups of the working system.
There may be an alternate explanation (Score:3)
I think it is possible that Microsoft is simply lying here and the whole insane claim is just an attempt to make AI, as offered by Microsoft, appear to have capabilities, it clearly does not have.
Just a thought. Obviously, they could also be insane and stupid enough to really attempt this.
with AI (Score:2)
"Copilot, turn this old C/C++ code into new, bug free, Rust code. While doing this add some more telemetry and more hooks to deliver ads".
job description (Score:2)
Our algorithmic infrastructure creates a scalable graph over source code at scale. Our AI processing infrastructure then enables us to apply AI agents, guided by algorithms, to make code modifications at scale. The core of this infrastructure is already operating at scale
He put some scale in his scale.
AI agents, guided by algorithms
Computers are guided by algorithms, amazing.
Even if you use AI, bullshit is still bullshit. That doesn't change.
3 Years of Experience. Well, preferred. (Score:2)
..preferably at least 3 years of experience writing systems-level code in Rust.
All that (cough, preferred but not required) “experience” to rip every line of C/C++ out of Microsoft software. A million lines per engineer per month.
If we thought Microsoft was about Job Security before, they just turned it into Social Security.
Not a "refactoring" (Score:3)
My prediction: the old pieces of Windows that somehow still work will become just like Microsoft Teams.
sic transit gloria Microsoft (Score:2)
Microsoft, like most corporate giants, started small with a founder or founders who had a good product or service. He/She/They proceeded to build the business, expand the product line, grow the customer base, and ... go public - effectively selling partial control to investors (who generally do not intimately know the business or industry and have only injected cash, but who get a board of directors and a say in the operation). Over time, as the company grows and time passes, the original person or persons
Re: (Score:3)
The company was born in the American culture with a team of young Americans (for better or worse) and this included the Yankee attitude that a person's personal computer was THEIRS and their data was THEIRS and what a person did with his computer was nobody else's business. Instead of leasing a computer and its OS, you could buy a computer and buy a Microsoft OS and then use it privately and securely and what you did with it was nobody else's business. The company's current CEO is not from the American culture (no, not skin color, CULTURE) and seems to not understand the entire POINT of the 1970s and 1980s microcomputer revolution. Not understanding the point, and not "getting it" on the independence and privacy stuff means he's gonna drive the company into a serious ditch at some point.
Unfortunately, I don't think the issue is Nadella, because the push-everyone-to-subscriptions-and-cloud isn't unique to Microsoft by any means. Google has pretty much graveyarded all of their desktop software except Chrome and Google Drive, which is functionally their variant of Remote Desktop (and yes, their Android dev tools). Adobe obviously made Creative Cloud a one-way trip, Salesforce has been cloud/subscription only from day one, and while AWS isn't the biggest share of Amazon revenue, it is their mo
Man, I'm in the wrong business (Score:2)
2025 Mythical Man-Month Award Winner (Score:3)
Runner-up: DOGE To Rewrite SSA Codebase In 'Months' [slashdot.org].
We have all (Score:3)
Re: (Score:3)
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.)
Re: (Score:2)
Re: Literally? (Score:2)
Well not figuratively, so I'd say yes.
Re: (Score:2)
Literally, rust?
Like, literally-literally?
By the time they’re done? Yes. Literally-literally.
Re: (Score:3)
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
Re: (Score:2)