Or are we talking about a semi-autonomous vehicle where the driver is expected to be alert, unimpaired, overseeing the vehicle's progress and capable of intervening for any reason?
Because for the latter it seems like there will be plenty of blame to spread around if the car does something stupid that the human overseer could have prevented had they been fulfilling their job. And if they weren't doing their job was that because they were drunk off their ass, playing on their phone or otherwise doing something that means they share blame for an accident?
Regardless, it was stillborn because it was prohibitively expensve. And not very good for all the tech either.
Most of Rust's safety is done at compile time and compiles away to nothing or is in the design of the apis that check you're not doing something dumb when you call them. So if you tried to copy a slice of a buffer in excess of a buffer it would panic but it wouldn't impact on performance any more than C code doing the same.
Obviously you can forego safety in C but that's the point Rust is trying to address - safety without penalising performance. That makes it perfect for IoT and its why the assumption that C can rest cosy because of IoT is a bad one. If I were writing any code for IoT I wouldn't choose C unless I had no choice. I might choose C++ assuming I could be sure of using only C++11/14 and nothing else. But I would choose Rust in preference to either of them.
I realise that's in theory. HTC have kind of fucked up in recent years and it's less to do with their hardware but how they've marketed them.
Yeah C is there and I haven't said any different. But it's a horribly dangerous language to code IoT and I expect that will reflect in the languages people choose to develop such devices over time.
We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -- Larry Wall