When I see a Rust post, I don't buy into the hype. It's usually compared with raw C, even C++. This is not a good comparison IMHO, since C/C++ has too many footguns/confusions.
Instead, compare it to a nicer/stricter "C" equivalent like Zig. Now, Rust doesn't shine as much.
I actually think embedded is one of the few places where rust makes sense.
In 99% of cases outside embedded, a GC'ed language would be better, but a long time ago someone started the meme that GC is slow, or that your users will notice the pauses, etc but those fears are massively overblown.
But on embedded where resources are constrained and you can't run e.g. a JVM then Rust makes sense to me, since you can eliminate a whole class of errors from the get go.
Ultimately, a lot of Rust's safety features (which I'd argue are desirable everywhere, regardless of performance) require the sort of precise tracking people complain about.
And once you have that, you might as well use it to free memory too. The idea of "Rust but GC" is fundamentally nonsense, because for GC to make sense you'd first need to rip out so much of Rust's selling point to begin with.
It mostly seems to come from a perspective of "But surely all this GC research must be good for something, right? Anything?", rather than a concrete idea of where the GC would actually help.
I would imagine that the kinds of embedded systems like cars would probably benefit from Ada instead.
Not only is there of course SPARK, if one wants to do formal verification, Ada has a proven track record in things like military applications. Of course, passenger cars don't have quite the same level of care needed as military stuff (although a lot of care is still needed since cars are hundreds if not thousands of kilograms and can absolutely kill people), but I could still see Ada being useful even in the automotive industry.
I’m not sure if that’s true. I’ve never been around things like airplane flight systems. I have been trained on other military hardware with instructions on how to reset it and under which circumstances. I wouldn’t be utterly shocked if an F-16 pilot learns that which such and such happens, you flip this switch back and forth 3 times and then turn this other knob to reboot the computer. You would never, ever get that to be an acceptable procedure for a car’s anti-lock brakes.
I'd say Ada is a great choice, but I wouldn't call it technically superior. Some Ada features are nice (e.g. delta types for fixed point calculations), some Rust features are nice (e.g. very expressive ML inspired type system with sum types, borrow checker helps with concurrency and memory lifetimes, ...).
Yes you can, that is the whole business of PTC, Aicas and microEJ.
PTC real time JVMs are famously used in military deployments, and you surely don't want pauses in a battleship targeting computer system (Aegis), or missile tracking system (thales).
>Yes you can, that is the whole business of PTC, Aicas and microEJ.
I'm saying that not all embedded devices have the horsepower to run a JVM. Nobody's running Java on the automotive equivalent of an 8-bit AVR, for example.
>you surely don't want pauses in a battleship targeting computer system (Aegis), or missile tracking system (thales).
That'd be the 1% of times when it does matter that I alluded to previously.
I even think on embedded it's overblown in terms of not being able to use a GC language. C#, F#, OCaml, Java (and I suppose all JVM languages), Erlang, Elixir, etc. can run on embedded devices, including some microcontrollers. In my opinion, the software industry has dug its head in the sand thinking that only "hard-core" languages can be run on embedded systems. Even LabVIEW could be a choice if the limited SoM hardware selection is okay. It's just as performant (if not more so for multicore systems) and infinitely safer than C/C++.
There are embedded Java systems. I hope you never have to work with any.
In general, embedded systems suffer from severe lack of tool developer attention. People standardize on the very few things that reliably work like C, C++, and printf debugging because they don't have the bandwidth for anything more. Anything outside the beaten track has a high chance of running into showstopping bugs halfway through a project and embedded teams are already struggling to find developer time in the typical situation of 1-10 people maintaining 1M+ LOC codebases.
Rust is the first real alternative to C and C++ in decades because it's actually trying to address the ecosystem issues.
Not even "printf" is included in any standard, I'm afraid. Arm's Keil MDK toolchain has an typical implemetation of baremetal C/C++ environment called microlib, but unfortunately it doesn't support RTOS because of the missing of re-entrancy, so you have to provide or use a third-party alternative.
I'm not stopping you from trying to put your theories to the test and I'm not saying the current reality is good. However, I think you'd be surprised how complex some of these systems are. An automotive system like the article is describing is a distributed realtime system of anywhere from dozens to hundreds of networked processors built without traditional operating system support. It's frankly a miracle they work at all.
While I don't work in the automotive field, I've worked on adjacent-esque distributed systems with some of the shared protocols (e.g., CANopen). Part of my lament here is that almost no effort has been put into anything other than running C and C++ on embedded systems. While hard real-time systems are a thing, other pieces have often still been implemented in C and C++, which is a shame. And it's also a shame that more effort hasn't been put into realtime garbage collectors, especially in this age of multicore embedded CPUs.
I fully agree that it's a miracle any of the existing stuff works at all. I honestly have no idea how C and C++ developers make it work. Despite being the oldest and most used languages, the tooling is atrocious.
Instead, compare it to a nicer/stricter "C" equivalent like Zig. Now, Rust doesn't shine as much.