Makes sense that one of the most safety focused manufacturers would go for it.

“ Why Rust is actually good for your car.” That gave me a chuckle. It’s a better title the one in here too

That’s nothing. Chevrolet has built its cars with rust for decades now.

I own a 2021 Volvo and the blinkers doesn’t blink regularly. They may blink fine for a awhile but then stops for a period, and then suddenly all missed blinks blinks in a rapid succession. It’s extremely annoying. There are other bugs, like when you are using the auto pilot where it sometimes may suddenly jerk the wheel even though there is nothing wrong with the road. Scares the shit out of you. That has happened thrice now.

I love Volvo cars. I hope they have enough investment in support and engineering, because Rust isn't an easy language to pick up. I wouldn't want to escalate minor software problems through the management that needs engineering team's response and I'm waiting because there is not enough people to support across continents.

Does it run on a GPU now?

can we make an estension that filters out anything with Rust in its name?

I have never done any Rust, but I love Volvo (I have driven 3 different Volvos) and I'd buy them without trying them (done it twice) if you want a car that is consistent and user-friendly, this is the one to go for.

Now I have a reason to try Rust.

Bit scary there is probably a bunch of code in a car explicitly marked as "unsafe".

Polestar is a Volvo subsidiary that does electrical vehicles that overlap a lot with Volvo's own EVs. Polestar 2 is their main model and its specs are nice, pretty much the second best after Tesla.

However what PS2 is also known for is an absolute shite quality of their firmware.

Cars refusing to start and requiring a "service" out of blue (with one lucky guy scoring this in the middle of a forest). Chargers not engaging or, better yet, not disengaging. Basic functions, like blinkers and car locks, breaking after an update. Updates, in general, are more of "oh, fuck, not again" events rather than the positive news.

Like, I understand it's a complex software. I had a Bimmer show at "-10 km to destination", an Audi refusing to open a truck if too close to the wall, but the amount of bugs in Polestar is insane over the baseline.

But, yeah, it's written in Rust. Yay.

[1] https://www.polestar.com

[2] https://www.reddit.com/r/Polestar/

Volvos software is absolute shit since they went with android

What are the most commonly used UI software for rust?

I don't think there is a QT equivalent? I guess there are bindings for QT, though, but I don't know if it plays well with the particularities of QT.

I can see where Rust could fill the same niche Ada once occupied.

Progressive on the cars, but their VIDA software uses terrible and slow database, and requires...get this: Internet Explorer to work on modern PCs.

They used to keep the rust in the chassis. Now it's on chips. That's progress!

Is this post being astroturfed or something? Lots of irrelevant, un-constructive or plain trashy comments

They're hard at work in this thread today; people must be convinced to buy Tesla, and to stay away from Polestar.

A lot of comments so far are complaining about the software quality in cars now. But what did you expect? This is what happens when you hire the same kinds of people to write the software for your car that you've hired for 25 years to write the terrible internal applications inside the company that everyone hates, and in the same terrible way. The end result is going to be exactly the same.

Over the years, I've seen various discussions brush up against the issue of professional certification. Professional Engineer, in civil engineering, is a serious credential, which can hold people professionally liable for bridges that fail, or buildings that fall over. Making cars a network of computers that all talk to each other, operated entirely "by wire," and giving up any consideration of mechanical backups (like with a plane) is going to very quickly drive the point home that the programming profession needs a similar credential. As a mechanical engineer who has made a living writing software for 30 years, I understand the difference, but the legal externalities are not going to care that software is VASTLY more complicated than, say, designing a plane wing with a factor of safety.

Now, I have to go figure out why my Rails application can no longer restart the delayed_job process on deploy. Is the problem in Rails, Ruby, my gems, Capistrano, permissions, SSH, or some updated package on my Linux VM? Designing a bridge, frankly, is easier, because it's "concrete" and closed-form. Sure, I'll figure out my deployment problem, but next month some obscure thing in the 24 layers that make up a simple web app these days is going to get updated, and break something else. At least once a bridge is built, it's done.

I remember proposing looking into introducing Rust as a second language next to C++ just 3 years ago while working with a German car manufacturer in Berlin, every single architect refused and most of them were making fun of me, anyway I'm not bitter ...

Actually back then it was the beginning of me stopping carrying about improving and just go with the flow like a dead fish. Everyone is happier, I have much less clashes with coworkers much less stress and you know what they say: Nobody got ever fired for choosing IBM.

I think this is the main reason for the state of software quality in cars now. People who care can't stand the industry and leave, if you want to stay you have to stop carrying.

Every automotive code base I've seen has been a dumpster fire. This (mostly) isn't the fault of the developers and Rust won't fix it. The business process creates this outcome. No one likes it but little is done to address it.

The software development timeline is slaved to the rigid manufacturing timeline. There is no allowance for slippage, so making things work By Any Means Necessary is the rule of the day. Concurrency problems often are not debugged; locks and similar are just sprinkled around until they disappear in testing. It is TDD taken to an extreme -- passing the enumerated tests, technically, is the definition of done even if the code is obviously poor or broken.

There are a vast number of software and hardware components sourced from myriad vendors that are swapped out every year to save a few dollars or deal with a supply chain issue. There is no stable baseline but all of these components need to work together. The code has to constantly adapt to the reality that someone sourced parts for a new model year that work differently or are in a different programming language.

This code is usually required to be supported for 10+ years. The developers don't just have this year's tech stack and code base to deliver on a rigid schedule, they are required to maintain several older implementations concurrently, often built in different languages and architectures.

Basically, the automotive industry has failed badly at the transition from being hardware manufacturing companies to being hardware + software manufacturing companies, and try to run their software processes the same way they ran their traditional hardware processes. Choice of programming language is the least of their concerns, that isn't the source of their code quality issues.

Honeslty I'd rather they just did as minimal programming as possible. Slap an open api on all cars and let carplay/android auto/any other piece of software have access to said api to do as they please.

The longevity of in car software is utterly attrocious. Taking a very basic car like a Toyota Aygo as an example, in 2015 they released their mid-range models with a large touchscreen in the center console, boasting support for connecting your phone and such. In reality it didn't work from day 1. They used Mirrorlink which had already become out of date tech and wasn't supported by any of the handsets anymore.

Now, they could've released a software update to fix this. Except they didnt. They kept selling that car for several years, advertising phone integration that didn't work.

Car manufacturers give absolutely no care at all to their software and never have.

So I guess this means Volvos will be... crashing... less?

It's fitting as Rust is the Volvo of programming languages (and I mean that in a positive way, much as Volvo characterised itself in its successful "Bloody Volvo Driver" advertising campaign).

I saw a lot of fairly unstructured C in embedded programming - copied source / header files, hacked together Makefiles, lots of "works on my machine". Almost no abstraction to prevent use-after-free (mostly rigorous code review).

I always saw that the problem it would solve is more about tooling - Rust would be a fairly good fit because it has a good cross-compilation story, and the tooling around e.g. cargo and running builds is quite good (in my opinion). The blocker right now is absolutely vendor support; no reasonable hardware company can afford to hack their own HAL without vendor support (and in fact they pay a lot for support right now, and use it).

I think what these companies usually miss (good for Volvo) is that iteration time in a "higher-level language" like Rust can actually be much faster than in something like C. The setup time for a dev environment in embedded can be a week (making sure exact version match between compilers, checking out files, compiling, resolving build failures). On top of that, just having access to a language with strings and algebraic types is huge.

I think there's maybe room for a Rust consultancy that could take one of the existing large manufacturers, build a toolchain around it (possibly with their blessing / support). Ferrous Systems does this (I hope there is as much demand as I am imagining).

I drive a Volvo and it's the most amazing car that I've driven. The comfort of long range drives is something else.

I'm an automotive technician, I have worked for an EV startup. Some of the most frustrating diagnoses I have been involved in were caused by bugs in the software. We had one where a power trunk would not release if the vehicle was out in the sun. The ambient light sensor and the power trunk actuator were not even on the same network bus. We had a gut feeling that it was software, but by the time we were sure, it had been 2 full days of extensive testing.

I know Rust has many goals on paper that align with this decision, however, what large codebases in the field of high-integrity software are written in Rust? Does Rust comply with high-integrity software standards (CENELEC EN 50128, DO-178C,DEFSTAN 00-56, or IEC 61508) in any capacity?

SPARK2014 has been around much longer, does comply with those standards, is a formally defined PL with a great set of verification tools specifically designed for high-integrity software. There are large codebases (software for the safe operation of helicopters at sea (27k LOC of SPARK2014); NATS iFACTS air traffic control system (>529K LOC of SPARK2014).

I am glad that AdaCore is teaming up with Ferrous Systems to help bring some of Ada and SPARK's goodies to Rust, but it's nowhere near them at this point. This seems more a Rust champion at Volvo convinced their group to use it.

>>>JG: Then I pitched to the managers, “If we want to do a serious Rust effort within the company, then I want to take part in that and become an employee”, since I was a consultant at that point.

The availability of programmers in either Rust or SPARK2014 shouldn't be a heavily weighted factor, since anyone working in SPARK2014 probably already has the relevant experience no matter how few apply, whereas the dozens or more of Rust programmers who might like working at Volvo would be cutting their teeth trying to build 1/20 of what Ada/SPARK2014 already have, and possibly deliver far less.

Rust is to C++ as SPARK2014 is to Rust at this point in my opinion, but current popularity wins out a lot in all human endeavors. I'll stick with SPARK2014 and Zig for now until Rust catches up SPARK2014.