3 ms·

Embedded systems: Rust, checked C and other languages or methodologies designed to act as a "safer" alternative to C will see little real impact in the near to

Embedded systems: Rust, checked C and other languages or methodologies designed to act as a "safer" alternative to C will see little real impact in the near to medium term future. Code running on microprocessors in medical, industrial and automotive devices will continue to be C99 (at best) for a very very long time.

adrianmsmith 5y ago
I have the feeling you're right, but why do you think this is? As someone not working in those industries, it would seem an obvious choice to move to a safer language, so there must be something I'm missing?
- oriolid 5y ago
  Tradition and machismo. Also, cost savings if there is a slightest chance that C or assembly produces smaller code. Source: I have worked with embedded software specialists. Including the type who just writes the whole thing in assembly because compiler can't optimize the first C effort.
- johnx5c 5y ago
  It's a combination of things. The first is the lack of expertise in existing companies and lack of available hires. Rust is new and has a steep learning curve. I work in a company with 7k+ engineers. Our Rust interest group has less than 20 members and most are beginners. I have never seen Rust mentioned on CVs even once when hiring for Embedded positions. The second reason is lack of tooling - specifically Functional Safety toolchains that can be used for ISO26262 projects. There are plans by Ferrous to develop one, but it will take years to gain any adoptions [1]. [1] https://ferrous-systems.com/ferrocene/ https://ferrous-systems.com/ferrocene/
  - scruple 5y ago
    I agree with what you're saying completely and have said so on HN in the past. It's my opinion that Rust won't break through the embedded world until the toolchains are there and I don't see an incentive for the vendors to do that work in the first place.
- hprotagonist 5y ago
  a thing you’re missing is the cost of code recertification. tens of thousands of dollars and several months of QA per release means that thanks very much but we’re going to keep using what we have because yours looks nice i’m sure but we don’t care.
vinnymac 5y ago
As someone who doesn’t write C regularly, or work in those areas, I am curious if you wouldn’t mind explaining how you arrived at this conclusion? Are you just hinting at the fact that these industries are slow to evolve, or is it something specific about the languages?
- johnx5c 5y ago
  Aside from the immaturity of the talent pool and tooling I mentioned in another comment, I think the embedded domain is incredibility slow to change. My team have in the last decade spearheaded initiatives like adopting Agile, C++ (subset) use, Git (as opposed to SVN/proprietary) and extensive use of modern code hosting and CIs and we've met with a lot of resistance in our company (and those we work with). I've also interviewed lots of experienced embedded engineers, e.g. automotive, who have never heard of Agile or used Git. I think it's a fear of change (risk) and also that the embedded engineering domain is so closely tied to hardware development, which is even slower to change.
JaceLightning 5y ago
This sounds like wishful thinking at best. I work for a company that builds very power-efficient microprocessor devices with all the firmware written in c. There has been talk about migrating to rust for a while and now some of the code is even being written in rust. Someday it will be 100% rust.
- johnx5c 5y ago
  I would love to work in a similar company but I can't see Rust challenging C any time soon with so few Rust developers available and no functional safety compiler on the market.
Flankk 5y ago
I agree with this. The ideal language has a minimum amount of complexity while also being human readable. C has stood the test of time because of its simplicity. You cannot reduce the complexity of a system by adding more complexity.
V_Terranova_Jr 5y ago
As much as I wish you were wrong, from what I see in avionics, I suspect you will be right. Many of the companies developing these products simply do not pay enough or have a suitable company culture to attract top-quality software developer talent. These companies will ride out legacy practices and mindsets for as long as they can get away with it.

adrianmsmith 5y ago

I have the feeling you're right, but why do you think this is? As someone not working in those industries, it would seem an obvious choice to move to a safer language, so there must be something I'm missing?

oriolid 5y ago
Tradition and machismo. Also, cost savings if there is a slightest chance that C or assembly produces smaller code. Source: I have worked with embedded software specialists. Including the type who just writes the whole thing in assembly because compiler can't optimize the first C effort.
johnx5c 5y ago
It's a combination of things. The first is the lack of expertise in existing companies and lack of available hires. Rust is new and has a steep learning curve. I work in a company with 7k+ engineers. Our Rust interest group has less than 20 members and most are beginners. I have never seen Rust mentioned on CVs even once when hiring for Embedded positions. The second reason is lack of tooling - specifically Functional Safety toolchains that can be used for ISO26262 projects. There are plans by Ferrous to develop one, but it will take years to gain any adoptions [1]. [1] https://ferrous-systems.com/ferrocene/ https://ferrous-systems.com/ferrocene/
- scruple 5y ago
  I agree with what you're saying completely and have said so on HN in the past. It's my opinion that Rust won't break through the embedded world until the toolchains are there and I don't see an incentive for the vendors to do that work in the first place.
hprotagonist 5y ago
a thing you’re missing is the cost of code recertification. tens of thousands of dollars and several months of QA per release means that thanks very much but we’re going to keep using what we have because yours looks nice i’m sure but we don’t care.

vinnymac 5y ago

As someone who doesn’t write C regularly, or work in those areas, I am curious if you wouldn’t mind explaining how you arrived at this conclusion? Are you just hinting at the fact that these industries are slow to evolve, or is it something specific about the languages?

johnx5c 5y ago
Aside from the immaturity of the talent pool and tooling I mentioned in another comment, I think the embedded domain is incredibility slow to change. My team have in the last decade spearheaded initiatives like adopting Agile, C++ (subset) use, Git (as opposed to SVN/proprietary) and extensive use of modern code hosting and CIs and we've met with a lot of resistance in our company (and those we work with). I've also interviewed lots of experienced embedded engineers, e.g. automotive, who have never heard of Agile or used Git. I think it's a fear of change (risk) and also that the embedded engineering domain is so closely tied to hardware development, which is even slower to change.

JaceLightning 5y ago

This sounds like wishful thinking at best. I work for a company that builds very power-efficient microprocessor devices with all the firmware written in c. There has been talk about migrating to rust for a while and now some of the code is even being written in rust. Someday it will be 100% rust.

johnx5c 5y ago
I would love to work in a similar company but I can't see Rust challenging C any time soon with so few Rust developers available and no functional safety compiler on the market.

Flankk 5y ago

I agree with this. The ideal language has a minimum amount of complexity while also being human readable. C has stood the test of time because of its simplicity. You cannot reduce the complexity of a system by adding more complexity.

V_Terranova_Jr 5y ago

As much as I wish you were wrong, from what I see in avionics, I suspect you will be right. Many of the companies developing these products simply do not pay enough or have a suitable company culture to attract top-quality software developer talent. These companies will ride out legacy practices and mindsets for as long as they can get away with it.