(that isn't what you said? what's your point?)
It's abundantly clear that there is a strong headwind towards memory safety, whether that's Rust or GC'd languages.
nit: except in aviation
It's beneficial on takeoff because headwind already factors into your airspeed before you even start rolling, which gives you more lift for the same groundspeed yes, enabling you to rotate sooner than you otherwise would.
https://www.businessinsider.com/3-aircraft-fly-new-york-to-l...
C++ is still indicated for systems that are optimizing for performance and scalability characteristics, since it intrinsically requires a lot of "unsafe" constructs.
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.
The problem is that it actually sucks for dealing with the encapsulated parts. The reason everyone loves Rust is because they can just import a package where somebody else did the hard part for them and not worry their pretty little brains about a thing, getting high performance with minimal concern. That is a valid advantage, and that does make more mundane usage of the language safer. But it does not make the unsafe parts safer. There is every reason for having unsafe-oriented languages with ergonomics that actually make working with unsafe code more reliable too. The annoying thing about Rust is that 90% of its users are religious dogmatists who insist that Rust is the only valid language rather than accepting different languages can have different advantages, and moreover that 90% is basically the 90% who are benefitting from Rust while not being the ones who have to write unsafe code themselves.
Btw, Rust ain't the only vector here. With an LLM at your side, you can also write your performance and safety critical parts in Lean and prove them correct.
Lean can compile to some pretty fast code. (Though it needs a bit more engineering work around eg SIMD to get really fast.)
unsafe {
mem::transmute::<&T, &mut T>(t) //takes a &T, returns a &mut T
}
To be clear, just declaring a block to be unsafe does not immediately do anything in Rust, it just allows a set of primitives that are not normally available, so it is possible to use unsafe judiciously without immediately stepping into a million landmines. You just have to be careful and ideally read the docs and the nomicon page for the operations you do, especially if they are very long.
It's harder to write unsafe code in Rust. That doesn't make it "unsafer". What I mean is this, if you want to write unsafe code in Rust the C++ way, your entire program has to have unsafe markers everywhere. It's just as unsafe as C++ at that point.
But if you want to write unsafe code in Rust the Rust way, you run into a requirement that didn't exist in C or C++: The abstraction around the unsafe code must be safe for you to drop the unsafe marker. This created a unique category of abstractions that no other language has, so if you are working on unsafe code in Rust you are often a pioneer doing something never done before.
Rust has some stricter and more complicated rules even than a language like C++. Just as in C++ you absolutely must obey these rules at all times. However, in Safe Rust the tooling will ensure that following those rules is never your problem. You don't even need to know what the rules are, just like you don't need to know why a plane works let alone how to fly it to get on a jetliner and fly across the country for $$$.
In unsafe Rust, it is your job as programmer to understand and obey these rules because the "unsafe super powers" you can use only in these blocks cannot be checked by the tooling, it can help sometimes but you can't rely on it. Writing ten lines of correct unsafe Rust is thus probably significantly harder than writing ten lines of C++. But the Rust programmer knows when they need to be at their sharpest, they need proper review by somebody paying attention, they need to slow down and think it through, versus the rest of the safe Rust where it's less scary, in C++ every line you write might be a fatal problem.
Basically, walking a tight rope is harder than everyday walking, but you know when you're on a tight rope, you've trained for it, everybody is focused on your safety - so actually maybe that's not a problem, lot of people get injured just walking about every day.
Either that, or we really need to keep improving C and C++ safety story, if they are to stay around on those language runtimes, or compiler backends.
Meanwhile when I run tests on my JVM projects it can take 30 seconds just to start and the test execution is extremely slow too.
Even if you do manage to match the performance after warmup, you still have the issue that keeping the class files in RAM plus the JIT compilation state will cost more memory than simply running AOT compiled code. You simply cannot write processes that use a single digit MiB amount of memory on a JVM and getting down to 2 digits is theoretically possible but requires significant effort.
Once you get into the micro optimizations like the lack of mutable aliasing in Rust, there is significantly more potential for auto vectorization.
What you mean by "real world systems" is probably defined in such a narrow way that all the weaknesses of Java programs don't count anymore.
Because it's referring to long running processes, AKA the kind of things where hot paths can be JITted into faster native code than is possible from static compilation because the JIT has information about the real-world usage patterns.
> Meanwhile when I run tests on my JVM projects it can take 30 seconds just to start
That strongly implies you're using some sort of framework that's doing a _lot_ of initialization. That's not JVM startup time, don't be intellectually dishonest here.
> You simply cannot write processes that use a single digit MiB amount of memory on a JVM and getting down to 2 digits is theoretically possible but requires significant effort.
Again, the main use case for Java is long running server processes. No one cares if the binary is 1, 10, or 100MB or if it consumes 2, 3, or 4x the memory as long as the throughput is there. And Java has a long track record of delivering very good performance in those contexts, coupled with an extremely rich and mature library/tooling ecosystem.
I think this used to be true more than it is now. Memory has been relatively expensive in cloud environments for a while (often 2x the price of an ec2 node for an equivalent with 2x RAM) and DRAM shortages aren't helping.
A poet can beauty in any language.
By real world systems, I mean long running real server-side systems that run things that you use day to day by large corporations serving millions of users.
Are you able to share some of the tests you are running, and which frameworks are you using? Now with project leyden and similar efforts, start up time has been cut drastically.
A disgruntled former Azure employee posting what a clusterfuck their SW, including their Rust effort is? That’s both rare and interesting.
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.
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.
(I have mixed feelings about that, but empirically it holds true.)
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.
Multiple redefinitions of enums - except they aren't enum but random lists of strings - that also diverge in different files.
Things consistently typed as `Any` or `dict[str, Any]` even though the functions clearly are expecting specifics, not `Any`
This is the worst MR I've had to review yet in my life. Absolute garbage.
LLMs are pretty bad at picking abstractions.
Sadly, agents don't mind generating gigatons of code instead of refactoring the abstractions.
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...