Yes indeed, Ada/SPARK would be better suited, but suffer (unfortunately) from a hefty price tag, not every shop is willing to pay. Especially if there are no lifes at stake should your software crash.

Rust has the (imo) above stated problem. Also, if you avoid dynamic allocation, Rust's advantages are not as compelling in the real world as advertised (personal opinion). They are there, but IMO minor.

The problem right now is that we have a chicken and egg problem. You said you work in embedded too, so you know MCU bugs exist. Use anything but the "recommended" tool chain, and the compilers will be blamed, no matter how much proof you have that it is the MCU.

Don't get me wrong, i'm definitely keeping an eye on Zig. There is lots to be liked. I cited that its goal is keeping the language simple. But only time will tell if the developers can keep up to this promise. I, personally, don't trust languages developed by communities in this regard. Reality has (sadly) proven me right.

When you say Ada has a hefty price tag, what do you mean, exactly?

(Are you talking about ide licences, the commercially supported version of the compiler, ramp-up time to productiveness, or maybe something else?)

Somehow I've become interested in the economics of Ada, and am considering it in comparison to several other strongly typed systems programming languages for a learning project. So I'm a bit curious.

There are still 5 surviving Ada vendors, only Ada Core supports a FOSS compiler, for most commercial deployments the compilers lie in typical enterprise seat prices with "talk to our sales team".

This new announcement for Zig makes it seems like in the future it might be independent of LLVM... Maybe it could support C compilation back-end one day. But for now it's pretty much LLVM based languages, or C.

Alas... not to mention debugging tools, etc. That's why I've gone down the Nim path at work as well, and it's actually pretty fun once you get the basics. Having JSON support in a few kB's of flash is nice. I've ported enough of the Nim standard library to FreeRTOS/LwIP to be able to use it with the ESP32! If you want to take a look and see how it integrates with FreeRTOS [1].

I'd recommend trying out Nim's new ARC garbage collector if you have more than a few dozen kB's of RAM. The ARC GC is pretty friendly to working with C based-boards as it can use the native malloc and any native debugger mechanisms. The references are non-locking to it's pretty low overhead, but if you do try it run `-d:nimArcDebug -d:traceArc` first to see the overhead. You can't use `async` without cycle collection (ORC) however.

Of course no-GC works too and you can annotate functions to guarantee no GC (I think). Just less fun if you have the RAM available.

1: https://github.com/elcritch/nesper (Warning: WIP)

The low cost of porting a C toolchain to a new platform is a feature of C. Arguably, it's one of C's two remaining "killer apps" that keep it in use. The other is that C is the "universal recipient" language for FFI - it's easy to call C functions from almost any other language (but not vice-versa).

It's currently much more expensive to port an Ada, Rust, or even C++ toolchain to a new platform, so I'd expect C to continue to be dominant on lower-spec chips. Here's a previous comment adding a bit more technical detail to that argument: https://news.ycombinator.com/item?id=22822931

The universal recipient for FFI is mostly a thing in UNIX like OSes, not so much on others.

It's similarly true on Windows - not everything supports COM.

There are more OSes out there.

Fair. So maybe C only actually has 1.5 killer features left, not 2.

It was true since ever actually, not only Ada83, Modula-2, but also since NEWP, PL/I, PL/S among other possible ones.