Rust is rolling off the Volvo assembly line

A while back, I had the fortune to talk with Julius Gustavsson from Sweden and he squarely falls in the last category of people. From 2019 onwards, he has been the main software architect for the low-power processor ECU (electronic control unit) at Volvo.

This ECU is responsible for the (low) power management of the car. Electric cars obviously have massive high-voltage batteries, but the classic 12 volt lines are still there. Those lines are always on and can drain the battery if there's any power usage, so you want all car systems to be turned off when you're away from your car. The ECU is responsible for waking up the electric system when needed, for example when you approach the car.

This ECU was not actively being worked on in 2019 and so Julius became part of a new dedicated team. But even back in 2017, when Julius joined Volvo, he already knew about Rust and saw its potential to replace existing C and C++ code.

It turned out the low-power processor was a perfect fit for using Rust! It was not classified as a safety-critical component and it was an Arm Cortex-M processor, so there was no technical or bureaucratic blocker for using Rust.

And so it has come to be that, at this moment, EX90s and Polestar 3s are rolling off the assembly line that would not work without their Rust components.

I think that's a great milestone for Rust!

I wanted to know more about this and thought the world would too, so Julius has kindly agreed to let me interview him. Here's everything we talked about:

Q: Why did you pick Rust?

Julius told me his first job was building air traffic control software, where a lot of Ada is used. A competitor was even required to use Ada by the US Air Force. "The language is amazing in its own way. However, the consensus at the company was that Ada was both too arcane and to proprietary for them, at that time."

And so he used a mixture of C and C++ for about 15 years. "At all different companies I worked at they all had different strategies and strictness, but memory-related bugs were always a problem".

"It always felt unsafe; Most codebases have a bunch of invariants and assumptions that are not written down but everyone must uphold. As the project grows in complexity and especially team size, this will inevitably fail at some point. After debugging the umpteenth bug, the thought came, 'Is this it? Isn't there a better way?'"

He had discovered Rust before its 1.0 release in 2015, and began paying more attention to it after the release. So when he joined Volvo Julius had a little bit of hobby experience. He had found it tricky to pick up the Rust concepts and had to read the O'Reilly book twice. However, "once it clicked, I got very enthusiastic."

Picking Rust for the ECU project didn't come out of the blue.

"When we were prototyping the precursor to the project, and doing interop with Android, I created a vehicle HAL in Rust using futures 0.1, back in the days before async, for Android that spoke grpc to the Rust system," he explained.

Describing the project, he said: "We'd have buttons on the screen to control the fans of the car. I had to write a lot of code before I could compile it all, a big jenga tower. But once it compiled, the fans started to work! Very impressed."

It was difficult to figure out how to build Rust for use with Android, which was the platform this prototype ran on. Today much more effort has been put in tooling around this, but Julius was there very early.

With this prototype he proved to himself and the people around him that Rust could be a serious option for production code; It delivered on its promises.

Q: How did it go?

Aside from the project being a good fit for Rust due to it not being safety-critical and running on common hardware, it was also quite straightforward due to its limited feature set.

In 2020 they had made a first proof-of-concept in C before continuing the project with Rust. What wasn't so straightforward was that the ECU had to communicate over CAN with the other systems in the car and they had to implement all diagnostics systems and port over the standard Volvo protocols.

So they needed to reimplement a lot of things. According to Julius though, they "got much higher quality". And they found they were writing far fewer bugs compared to C and C++.

Julius wasn't the only one really liking Rust. One of his colleagues had to leave and said: "It's hard to think about having to go back to something that's not Rust". Still, a healthy dose of scepticism remained. As Julius put it: "I always had the feeling, is Rust too good to be true? I'm always looking for the big pitfall. So far I have not found anything bad. Only some small things like const generics not being fully done."

As the project progressed, they got "a bigger and bigger pile of proof that Rust does actually work well".

There were regular cross-team meetings where team leads could discuss their problems. As time went on it became more and more noticeable that Julius didn't bring up many issues at all and when he showed his results, his colleagues were often left impressed.

Q: Would you recommend Rust to others?

"Definitely", Julius answered promptly.

He continues: "For any project where you have very strict reliability and availability requirements, and you want to be confident that what you deploy is actually correct, then Rust is an excellent choice! Also cargo and all the other available tooling make the whole cycle of developing high quality software a really nice experience."

Rust also works great for teams with high turnover because there's a lot of confidence in the code. "Other people can just take over the code and fiddle around safely because when it compiles, it almost always works".

"For prototyping, then maybe it's not the best option because things are rigid. The compiler forces you to work more on the edge cases and minute details up front, something you are not always interested in doing at that particular point", he noted. This, of course, is an often expressed sentiment.

But to put that in perspective, Julius says: "Rust would work for most of the software I've worked on professionally. There are absolutely cases where Rust is not the best fit. But I think we're at that point where instead of asking 'Can we use Rust for this?', we should be asking 'Why can't we use Rust for this?' And then you have the discussion."

Q: What's missing that got in the way?

It wasn't easy to create the software so that it properly fit the requirements, according to Julius. This is mostly a tooling issue.

For example, it was hard to run the unit tests on the embedded target. Other challenges included code coverage, runtime profiling, software BOM and license tracking. This is my personal experience as well, although the state of these issues has much improved over the last couple of years.

Julius and I agreed that it would be very valuable to build more and better tooling. He said: "Most are halfway there, but you still need to do a lot yourself".

During the project, things got better. Julius explicitly mentioned the Knurling project, for example, and that those tools helped a lot.

Q: Are you going to use Rust in the future?

"Yes."

In fact, Julius is actively cheerleading for other projects to pick up Rust. And there seems to be an overall enthusiasm for Rust at many layers in the company.

A couple of days before my meeting with Julius, he had the final project presentation with the management. The result of that meeting was a common consensus among management to look into using Rust in more places.

Conclusion

From our conversation it seems that using Rust has been a great success at Volvo thus far. People are happy, the quality of the product is high, and the company seems poised to use more Rust in the future.

It's obvious that there's more work to be done still, but with more safety-critical tooling like Ferrocene becoming available, Rust is readier than ever for use in the automotive industry.