Relevant (for those who don't want to watch video):
- 3000 pages of specs
- 1 million LoC from suppliers (because you use different systems from different suppliers)
- 200 problems
- of which more than 100 problems were in the standard itself (standard being AUTOSAR that described how different parts from different suppliers communicate with each other)
What could be an important change is the culture. At the very least, developers who tend to pick Rust may be (hopefully) more inclined to do things the right way and don't just slap shit on the codebase until it sticks. I've seen way too much of this attitude in embedded developers.
And another important change could be management policies. If they are conscious to pick something uncommon, they might have better tolerance toward spending more time but doing things properly, than pushing people to release whatever seem to work (somehow).
I'm pretty sure a lot of bullshit in IoT happens because management want to release things as fast as it's possible, and developers either don't care or can't fight it.
Cars get tricky, though, because bugs can lead to loss of life.
The business processes force the engineering work product to be a dumpster fire.
The great companies dont.
It does sound like Rust could help here
But even then that's usually abstracted away and then a safe interface being provided.
ten_things[11] = blah; // is a buffer overflow so it either won't compile or it panics
However
unsafe { ten_things[11] = blah; } // is still a buffer overflow, same effect but also Rust warns that unsafe is useless here and should be removed
Now of course we can write a potential buffer overflow in unsafe Rust, but now we're not just sprinkling unsafe on stuff and hoping, we've got a plan, perhaps a stupid plan but it's a plan so that's an improvement.
Which goes to show that usually the unsafe methods are more verbose and annoying to deal with. Devs won't reach for them just out of laziness.
Still based on my experience reading early Redox code it was chock full of unsafe blocks, and I suspect they didn't do that out of malice but to expedite development.
So the risk might still be there.
https://doc.redox-os.org/book/ch01-07-why-rust.html
This is probably not an up to date number but it gives you some idea of a random snapshot in time at least.
Would be interesting to see what those figures were like 5 years ago (i.e. a year or so after its initial release). It seems like the concern here is that embedded Dev for cars isn't getting getting to maturity.
Even OS kernels are borderline, and it's still being figured out how exactly Rust fits, but yes we are slowly moving in that direction. Kernels have a lot of logic that qualify for the safe zone, and software engineering culture that is... let's say ahead of automotive.
This is a bit of a misconception for people who've not worked with unsafe Rust. It's not like the language and most of its features disappear. It just allows a few extra features that are unsafe, like working with pointers... Which, granted, is a lot of interaction with hardware. But you can kinda "cordon" this to a small subset of the codebase dedicated to this low level hardware IO
I'm not really an expert in embedded systems, so take this with a grain of salt, but that doesn't track with my experience or with my theoretical understanding of embedded systems. First off, embedded systems are just regular systems with tighter constraints and less high-level constructs. With that understanding, if embedded code is unsafe... so is any code on any system.
Second, embedded systems have peripherals that are accessed via direct memory reads and writes. Which is only unsafe if access to those peripherals is shared in an unsafe way. Sure, the rust code that reads and writes to memory addresses will use `unsafe`, but everything above that can be written without using unsafe. Which I guess makes your statement technically correct, but imo not practically correct
If anything Rust has a clear boundary, and that's useful for all kinds of static analysis.
And I say this as a fan of D lang. I don't really see any advantage of Rust over D except popularity.
But referencing the parent comment's discussion of business processes, its highly unlikely the problems will appear until Volvo tries to move to some other vendor or swap out the software solution for the next greatest thing.
More complicated than what, C++ which is probably what was used before? It's unlikely to be more complicated in that case.
I'm curious to see if the Rust programmers affect the organizations as well by introducing unions to combat this kind if thing.
On another note I disagree that language will have no meanigful effect, even in a hostile environment such as this.
Whatever ethos you imagine Rust developers uniquely have, it doesn't address any of the constraints and incentives that are creating the code quality problems in automotive. Even the best developers in the world would have a difficult time producing a quality product in that environment.
They tend to seem more of the type to go on strike, form a union, or leave a job because of political views.
> Even the best developers in the world would have a difficult time producing a quality product in that environment.
Right, i'm saying I think at least more experienced rust developers would refuse to work in that environment.
They seem like they would risk more of their own well-being for ethical reasons, for better or worse.
I suppose if Volvo started depending on highly socially conscious domain experts and had a choice between changing working conditions and ditching rust though, they'd change the latter.
I'm happy to be proven wrong, but experienced C programmers seem to be more conservative "don't mix politics and programming" types.
It's amazing that you're saying all that and the same time completely oblivious to the fact that Volvo is in Sweden. Which has unions, labor protection, amazing working conditions etc. etc.
The reason Volvo is doing what it's doing is due to Volvo's commitment to safety [1] and not because of some mythical exclusively social ethos of some programmers.
[1] https://www.volvogroup.com/en/about-us/traffic-safety/safety...
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.