5 ms·

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

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.

sham1 2y ago
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.
- kstrauser 2y ago
  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.
- stackghost 2y ago
  Yeah I agree that Ada is probably technically superior but when has that ever swayed anyone.
  - carlmr 2y ago
    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, ...).
bmitc 2y ago
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++.
- AlotOfReading 2y ago
  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.
  - Eplankton 2y ago
    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.
  - bmitc 2y ago
    I think the thing is, if you don't use C or C++, then you don't need a million lines of code.
    - AlotOfReading 2y ago
      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.
pjmlp 2y ago
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).
- stackghost 2y ago
  >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.
  - pjmlp 2y ago
    An 8-bit AVR can't even run proper ISO C.
Nullabillity 2y ago
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.

sham1 2y ago

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.

kstrauser 2y ago
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.
stackghost 2y ago
Yeah I agree that Ada is probably technically superior but when has that ever swayed anyone.
- carlmr 2y ago
  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, ...).

bmitc 2y ago

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++.

AlotOfReading 2y ago
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.
- Eplankton 2y ago
  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.
- bmitc 2y ago
  I think the thing is, if you don't use C or C++, then you don't need a million lines of code.
  - AlotOfReading 2y ago
    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.

pjmlp 2y ago

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).

stackghost 2y ago
>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.
- pjmlp 2y ago
  An 8-bit AVR can't even run proper ISO C.

Nullabillity 2y ago

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.