Rust at Volvo Cars
35 points by jmillikin
35 points by jmillikin
That preposition is important, because you don't want Rust on Volvo Cars.
While Rust has clear advantages, full rewrites of production systems are usually not worth the effort. However, I agree that code handling untrusted input data are important to evaluate and potentially rewrite to improve the overall system security.
I'm curious to see the long term effects of increased Rust adoption. How big of an impact will this have on decreasing the percentage of security issues related to memory unsafety? Will the 70% stay constant or drop further below?
Google made a blog post about introducing Rust in Android, where they had significant reductions in memory safety vulns.
We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one.
https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html
Most relevantly: they instituted a "no new code in unsafe languages" policy. You can still edit existing C/C++ components, don't write any new ones.
An important piece of context is that typical automotive software is of shockingly poor quality. The craftsmanship of code is often so poor that if you did not understand the incentives and processes that produced it you might assume malicious intent.
This is one case where "rewrite it in Rust" is likely a good idea. In my experience concurrency bugs are common due to heavy multithreading across many opaque modules with little thought put into architecture. Forcing even a little discipline at the language level would be an improvement. Regardless, rewriting in Rust seems unlikely to make the situation in automotive software any worse than it already is.
I frequently wonder how many of the "we rewrote our system in Rust and got 10x performance" posts are simply due to dropping tech debt en masse, and not because of Rust itself.
These aren't unrelated. Rust allows dropping of tech debt that would be infeasible otherwise.
In C, refactorings are more dangerous and big changes are more costly, so you prefer to keep the codebase "stable" and "battle tested" to avoid squashing all those bugs all over again. In C safety-related assumptions are implicit and spread throughout the codebase, instead of being either locally self-contained or automatically checked by the compiler (e.g. if you introduce threads and need to know for sure if some struct might be accessed from another thread, in C you have to review all uses of that struct, and all code leading to those places. In Rust you mark it as non-Sendable between threads and immediately see what failed to compile).
You're right that Rust can make refactoring easier, but you're missing GP's point. You only get those benefits once you have a Rust codebase you want to refactor.
If you're throwing everything out, dropping your technical debt is as easy as rm -rf, no matter what language you used. No refactoring needed.
Of course now you have to write your new system. But it's easy to imagine your new C program being 10x faster than your old one because your new design is more fit for your current requirements (and because you learned a bunch writing the first version).
I know this argument, but I don't like how nebulous and kinda tautological it is. It's about imaginary scenarios, so you can always invent scenarios that make it true.
I can't argue that there can't be any hypothetical rewrite that just got a 10x better algorithm or architecture.
So I'm skipping to the next question: if such a major improvement was possible in C, why wasn't it done earlier? How it ended up with a 10x worse code that couldn't be fixed without a rewrite? If you say it's just hindsight implying all else is equal, why wasn't it rewritten in C instead of Rust?
My argument is that Rust having these wins is not a coincidence. C codebases are harder/scarier to refactor. Language fragility taught people to keep things "stable" and "don't fix it if it ain't broke", so C codebases are more likely to be left with old architectures, old algorithms, and don't get modernised in-place, until they ossify so much that a full rewrite is a quicker option.
Full rewrites are a big gamble. Rewrites of C code in C only have an upside if you discover these architectural or algorithmic wins, otherwise you just wasted lots of time to get minor cleanups. OTOH a rewrite in Rust gives you a safer, more modern language on top of the algorithmic wins.
I can't argue that there can't be any hypothetical rewrite that just got a 10x better algorithm or architecture.
So I'm skipping to the next question:
I mean sure? But that’s the question that GP was asking. It’s a good question! One worth engaging with. And I’m curious about possible answers.
If someone reported “we wouldn’t have been able to get this speed up if we had rewritten in C instead of Rust,” that would be very interesting! If someone felt that way about a rewrite they were part of, I’d want to know about their experience.
When and how rewrites get justified is also a good question – Rust has lots benefits for a new codebase. But it’s a different question.
Most Rust rewrites from C++ to C are not talking about performance improvements. You don't adopt Rust because it's faster than C++ or C. At the most it's on par with them. Instead they talk about things like a 70% drop in security vulnerabilities and a faster pace of development.
At the most it's on par with them.
That's not necessarily true, especially coming from C, as it's easier to use and be confident in more advanced data structures in Rust than it is in C, and such data structures are easier to reuse. That's even one of the first famous "tales" of rust: https://bcantrill.dtrace.org/2018/09/28/the-relative-performance-of-c-and-rust/
I was deliberately not counting the capacity of a language to encourage specific performance patterns. The data overall indicates that language wise it's probably a wash but that specific instances in either language can leverage elements of the language to produce superior speed over another.
For context, I work in automotive software (C++, though there's been some light push from developers to start looking into Rust, but nothing major yet).
The majority of the software on a car is either fully contracted out and comes with an ECU as a sort of black box, and would probably be more minor stuff like tire pressure sensors or something, or is developed via a mix of in-house development and a lot of contractors. If it's a contractor, a lot of times that might not even come with code. If it does, this code is often of astonishingly poor quality. At the company I work there's been a push to get more and more development in house, so at the moment a lot of that kind of software is being re-developed from scratch (with much better standards). Even without that, moving to a new car platform often has so many changes that software has to be substantially changed, so a rewrite is happening whether it's in Rust or not.
Also it's important to note that there is a lot of variety in the kind of software a car runs. There's small microcontroller-like stuff, such as the subject of this talk, there's full-blown Android apps running on the infotainment system (which is not really safety critical), and everything in between. You might have an ECU with Linux, another with QNX, and many with some embedded RTOS, and these will all have a lot of different software with different responsibilities and importance, and each individual car will have a different combination of these depending on what options you've bought and what year it's been manufactured.
But just as an anecdote, I work on a relatively small application that is not safety critical, but runs along safety critical stuff. This is C++ code running on a full operating system, which gives us some much needed process isolation from safety-critical stuff running on the same system, so we can have more relaxed rules. We've been rather careful to avoid memory unsafe stuff so I'd estimate maybe 30% of our issues have been memory related and it's been going down as the code matures, but there's a ton of constructs which are just straight-up banned because they're so hard to misuse, and Rust makes this so much easier to deal with:
std::move.And just the fact that Rust makes refactors much easier to do has a major impact on productivity. I hope this trend spreads across the industry, because it's really impactful.
Very insightful - thanks for sharing!
Agreed, refactoring Rust code gives a huge boost to productivity. Similar to the transition from JS to TS for web dev back in the day.
I think it’s even more impactful. This software is really hard to update. If it’s possible at all, it’ll probably involve a recall of sorts, and an update might need to be approved by regulators of several countries, so bugs are expensive. If some software has major issues found close before the start of production, it’ll probably just not be shipped at all, meaning the company wasted potentially millions developing it (at least if it can’t ship later), but the cost of a recall would’ve been higher. Rust is just an all around win.
Carmakes clinging on to legacy software are going to be left behind. Historically, they had disdain for software, and hated upgrading hardware, so they probably have lots of legacy code for obsolete chipsets, which is not worth keeping.
I know loss of fully analog hardware makes car fans sad, and carmakers have been shitty opportunists using it for lock-in, but the ship has sailed over a decade ago. Most sensing and control is done in software. There are safety requirements that require driving assists. Customers expect infotainment that doesn't suck, digital keys, HUDs, remote control. EVs could theoretically be almost entirely analog, but competitive range and charging speeds need optimized heat and energy management.
I am currently in the process of rewriting an interpreted programming language in rust, which i initially wrote in c. Encoding invariants and errors in the whole stack feels so much more direct and assumptionless than in c. I have fun working on it again and even added 1.5x the features in half the loc. (One could say thats due to me know knowing about the unknown unknowns)
I think Ada would have been better option if they had to choose safety programming language
Cool thought, but why? This comment is devoid of context and doesn't really add anything to the discourse.
Agree with you.
https://www.adacore.com/press/ada-and-spark-enter-the-automotive-iso-26262-market-with-nvidia
Do you have any context for this or am I supposed to assume your opinion on "why" is a copy of this link ?