Comment by gregw2
20 hours ago
Those interested in this may find the following articles of interest:
Microsoft goals [edit: err, Microsoft hiring manager vision-casting goal ] to convert 1 billion lines of code to rust by 2030 via automated tooling enabling "1 engineer, 1 month, 1 million lines of code": https://thenewstack.io/microsofts-bold-goal-replace-1b-lines...
DARPA work towards automating converting C code to Rust using a mix of 6 different teams using different approaches: https://www.darpa.mil/research/programs/translating-all-c-to... Feb 2026 Progress report: https://github.com/DARPA-TRACTOR-Program/Reports/blob/main/F...
That is not "Microsoft goals", that is "one employee's LinkedIn comment of his personal goal".
It's less one guy's plan and more one Microsoft Research team's research goal to investigate technologies that might enable that in a few years. So probably more institutional support than just some guy, but less actually planning on succeeding in the full ambitious goal.
No, after this made some waves he or some other senior (I don't remember exactly) reported that this is not an official plan.
1 reply →
what's your point?
There have also been repeated statements from NSA & CISA that they recommend all development should be done in memory safe languages.
It's abundantly clear that there is a strong headwind towards memory safety, whether that's Rust or GC'd languages.
A headwind makes it harder to advance in the direction you're going. I think you might have meant to say "there is a strong tailwind towards memory safety".
You're right, I better do a 360 on my comment ;)
8 replies →
> A headwind makes it harder to advance in the direction you're going
nit: except in aviation
7 replies →
The recommendation is qualified for typical apps that do not have extreme performance or scale requirements. They use Java for many, many things.
C++ is still indicated for systems that are optimizing for performance and scalability characteristics, since it intrinsically requires a lot of "unsafe" constructs.
> C++ is still indicated for systems that are optimizing for performance
The only evidence I've seen for this is that people with a vested interest in my believing this keep saying it is true. That's the exact same evidence I have for Trump having triumphed in Iran. Do better if you want me to believe you.
> since it intrinsically requires a lot of "unsafe" constructs.
This is an excellent reason to choose Rust. The whole point of Rust's technology is to enable you to encapsulate the tricky difficult part of the problem so that people don't blow their foot off working on the mundane parts of the software. And the truth is there are always mundane parts of the software.
I'm feeling generous so I'll add more here: Vec<T> illustrates how this works. This is a growable array type, C++ has std::vector<T> for much the same concept. But inside Vec<T> this encapsulation is used heavily so that there's a RawVec<T>, which doesn't care about knowing how many things are in the growable array, only about its capacity, then a RawVecInner which doesn't even care what things we're keeping in the array, it's just an appropriately large container for whatever it is, that RawVec<T> remembers what T is if that becomes important - and then a Cap which doesn't even contain things, it's just in charge of being able to represent the capacity correctly while having the same shape as "just" an integer but not always necessarily working like one.
Vec<T> is entirely safe to use, very pleasant, no danger. But internally it's extremely sophisticated, hence the layers of different types encapsulating different pieces of the problem to make a growable array type with excellent performance.
9 replies →
In real world systems, Java can beat programs in compiled languages like C++ and Rust when it comes to throughput and even latency.
7 replies →
It would be possible for me to give a more nuanced take, but the upshot is: none of that shit is going to work 100%.
One may get local maxima like an unsafe bonanza, or something that introduces a custom runtime memory management discipline at the cost of performance etc. Fully equivalent C++ to Rust in full generality is mainly wishful thinking. Of course that does not mean one should not try it.
See also my other comment.
Oh, I 100% agree. The question is how much you can reduce the effort of the port/migration, and in particular the validation effort.
I've worked on projects where the core bits of code were "90%" converted by some automated tool, and in my view the overall benefit to the project timeline was probably only 20-30% because of the Amdahl's-law-type overheads of validation and bits of code not supported by the automation/conversion process. Nice, but no silver bullet.
Non-idiomatic porting also isn't super-helpful if the resulting code isn't maintainable.
As I pointed out in a sibling comment, the plan isn't for it to work. This is a job posting for a researcher at MSR to investigate what it might look like someday.
What with this llms not so good in rust mantra? Something changed? In my experience they are pretty good, but haters gonna hate.
LLMs are unusually good at Rust; it's an optimization target. And the constraints provided by "successfully compile with the Rust compiler" make it work well for agent iteration.
(I have mixed feelings about that, but empirically it holds true.)
Yes, I found these agents to be better at producing acceptable Rust than at producing acceptable Python code.
In addition to the Rust compiler, you can also tell them to make clippy happy. Both in normal mode or if you are feeling nitpicky, you can also tell them to make clippy::pedantic happy.
3 replies →
Most people it's good at syntax and the error messages give you a good loop. But the domains rust actually makes sense in tend to be quite punishing on slop both culturally and technically.
To add to this, I find that the delta between the amount of code and pain you get with good and bad abstractions is substantially higher in rust than other languages. It's alright to muddle through in Python or TS, but with Rust bad abstractions are punishing.
LLMs are pretty bad at picking abstractions.
3 replies →
There is no way they can re-write everything in Rust by 2030. No way. Even new projects are modern C++ at MSFT. Some teams are creating their Rust/C++ binding but that's a very small fraction.
Just in case slop is not strong enough.
These kinds of sanitized corporate, feel-good articles are anything but interesting.
A disgruntled former Azure employee posting what a clusterfuck their SW, including their Rust effort is? That’s both rare and interesting.