Now I have a reason to try Rust.
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.
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.
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.
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.
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.
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.
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).
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.