https://www.f-secure.com/en/consulting/foundry
https://developer.arm.com/solutions/internet-of-things/langu...
But also C isn't just for Intel, x86 and (some) ARM CPUs, there are other targets it has.
Any example with language extensions to ISO C, allows me to provide a counter example with language extensions.
Any example where only a subset of ISO C is allowed, allows me to provide a counter example with a language subset.
Sorry if I misunderstood it.
That said, people use C because it forgoes abstractions and complications. Neither C++ nor Rust provide that experience. I think Go comes the closest, while being a bit nicer to work with overall.
But at this point you know C++ pretty well (including all what you don't want to use, take a look at the CPP Core Guidelines), and using Rust is almost trivial, since Rust doesn't really introduce anything really new you wouldn't be already familiar with.
At least that was my experience.
https://github.com/michal-z/zig-gamedev
I like Raylib, and there are bindings for most popular languages, but I like the minimalism I can start with fairly quickly in Zig. I tried Bevy for Rust, but it is a lot more involved, and Rust, so Zig it is for now.
For safety, and high-integrity software, I am sticking with SPARK2014. Rust will get there soon, but Ada/SPARK2014 have such a lead, maturity, and industry take up that I am putting Rust down for another year or more.
Zig might be the most direct upgrade from C, but it seems like rust can mostly replace the entire concept of portable assembly, since it has zero cost abstractions.
C is not a language known for high security or reliability, nor is it known for being fast or easy to develop in, so by my guess based on vague anecdotal evidence, it seems that defaulting to the highest level of abstraction unless forced to do otherwise by some specific requirement is a better plan.
C and direct C replacements advertise simplicity, but if the simplicity doesn't buy you any reliability in practice, why bother with it?
There's almost no C code you could write in an effort to "forego abstractions and complications" that isn't also C++.
But although google has killed 264 projects so far [1], I believe that Go has too many dependents at Google and in industry to cancel. And even if it should happen anyway, the community will fork it.
FOSS projects die all the time. You might want to write a patch here and there, but do you want to do all the DevOps, pay for hosting, manage testing, etc?
Maintaining a project kinda sucks.