[ironman1478]

Probably because of

1. Inertia. its already being used, so why not keep using it? I can't prove this, but it feels true

2. Lots of microcontroller vendors provide tooling for it. You are basically guaranteed to be able to run C on whatever micro controller you want. Even if you don't get a standard library, you can implement your own if you need to. Languages like C++ have large runtimes and are hard to port to lots of platforms

3. Its an "easy" language to use for people who work on these devices and the problems of an ECU are not the problems of a database for example. I've worked on large enterprise databases and now I work on cameras for a car-ish company. The scale is just different and you simply don't need as many features as in C++, haskell, rust, python. The hard part on a small embedded system is not the coding per se, its the algorithms. A lot of these devices work at fixed rates on a timer (or respond to a very periodic interrupt), have a well understood amount of work to do in a fixed window of time, and then go back to sleep until the next job is queued. Memory safety won't help you when critical failure is defined as being late to respond. Would I love to have total memory safety at the moment? Totally! But its the least of my concerns at the moment and if my toolchain doesn't support it, then oh well we just have to code to the standards of misra and follow standards like iso26262.

I should say, writing C on a large project sucks. I've seen it before and I personally hate it (large portions of the database were in C). Its just too complicated and while C++ isn't perfect, having things like a destructor and templates are really nice and just makes the problems tractable.