Hacker News Reader

Comment by johnx5c | Hacker News Reader

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.

View on HN

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?

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.

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.

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.

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.

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.

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?

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/

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.

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.

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.

Reply on news.ycombinator.com