← Back to context

Comment by bregma

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

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.