Comment by bregma
7 hours ago
I work maintaining the toolchain and language runtimes for a commercial safety-certified embedded operating system. I am deeply familiar with C and C++ because I live it and breathe it every day and have done so for over 40 years.
Most of our customers use C, probably for historic reasons but also because it is much much easier to reason about and that becomes very important when auditing for functional safety certification. If someone's life depends on your software, you really want to be able to reason about its correctness because orange jumpsuits enhance no one's complexion.
Many of customers are now using C++. From the problems they have reported, well, they just shouldn't. It's not that it is a bad language (it isn't) or that it is inherently unsafe (it really isn't: exceptions are safer than propagating return values as long as you use them in exception conditions, because not catching one will return you to a designed safe state very quickly, and RAII is the best thing since sliced cheese). It's that cutting and pasting from Stack Overflow, and now vibe coding, makes for massive codebases that are next to impossible to reason about. I now see a lot of problems from customers where my first reaction is "don't write code like that" and "you can write bad JavaScript code in any language, can't you?". While it butters my bread and I enjoy the language, I really recommend against using C++ for safety-certified embedded software. Stick to C.
I think this hits the nail on the head. All the features of C++ help you write a code which you should have written in a much simpler way in the first place.
If only C actually had fat pointers as Dennis Ritchie, one of the authors, proposed to WG14.
It is quite relevant to note that the C authors, were keen to explore Alef as alternative on Plan 9, and based on the learnings reduced C's role on Inferno, and eventually took part in Go's design.
Even though they were not keen into using C++ (Plan 9 doesn't even support it), they were also aware C wasn't to be used for everything.
> I really recommend against using C++ for safety-certified embedded software. Stick to C.
You're almost certainly better off with Rust at this point or, if you must have C-like development, Zig.
Neither Rust nor Zig are appropriate at this time for certified functional safety. Given the definition of the languages is "it does what one particular implementation of its compiler, runtime, and standard library does at this time" it's not possible to construct a workable safety case for their use.
Enthusiam and neat ideas are not sufficient to certify a development tool for functional safety.