>C is C largely because its so stupidly (and impressively) portable; if you aren’t drawing that benefit, its likely a case of the wrong tool for the job.

I'm working in medium sized embedded systems (not embedded Linux, but also not the smallest embedded systems). I've only rarerly worked on 8 or even 16bit Microcontrollers. Most of what I work on is 8bit chars, 32bit, Little Endian normal Microcontrollers.

I really don't need the portability, the targets are all the same, however they only have C/C++ compilers. And we can't use GC. Rust would be a very nice choice at least for the application code. I'm not sure how to write low level drivers in Rust, but with FFI I would just push that to the boundaries, and make at least 90% of the applications Rust. But there's no LLVM backend for most embedded processors I work with, and even if there is, the maturity might not be there, and no company would switch to that considering that the next target might not have a backend.

We have to use C, because it's the only thing that we are offered. But for desktop applications I see no real reason to start something in C nowadays.

Some microcontrollers do enjoy Basic and Pascal compilers as alternatives to C.

https://www.mikroe.com/compilers

But as you say, the company needs to give the option to developers.

The point is that we already have millions of lines of code written in this less-portable C dialect, and probably thousands more are written every year. So no, it's not the same as a new language (for which all that code would need to be rewritten).

I think in a lot of cases it’s the only tool for the job. I have a hunch that a significant majority of the machine instructions executed in a given second globally came from C source code, and a large portion of that is running on something “weird”. It’s somewhat funny, “commonly portable” C is portable across the most uncommon C execution environments.

psst, your personal website is returning a 502

Thanks for the heads up!