C and C++ still seem to be prevalent. At least in my experience, rust on a microcontroller is still mostly theoretical. There's plenty of obscure languages, though, both compiled and interpreted / virtual machine based.
For "embedded" linux grade CPUs, rust is starting to gain some practical traction. A few years ago the idea of writing application level glue code in it was still a bit silly, but these days it's starting to actually get linked into production systems. It all seems to be done in a way that's interoperable with existing C/C++ codebases, though.
Explaining my experience - I haven't done any hardware or firmware programming besides messing around with Ardunios. I have written a low amount of C (tiny VM for toy language) and a moderate amount of Rust (a couple thousand lines for various projects, mostly console apps that needed to run fast).
It sounds like you have some experience in this and I have been curious for a long time why Rust can't or doesn't run on almost every micro-controller? Is it based on the compiler? I thought that because Rust has no runtime/produces a binary which does not require a runtime that as long as the Rust compiler emits the right backend instructions it should just work?
Adding to my confusing, I think rustc uses LLVM which is a way of separating a language's frontend from the backend code emitted, so I thought any micro-controller supported by LLVM would work for Rust.
My day job is writing Rust code for microcontrollers.
What you're saying isn't wrong, it's just that... embedded development is incredibly diverse. LLVM doesn't support as many platforms as GCC does, and even once LLVM gets support for something, we need to do some work in Rust to get things working; support isn't automatic.
If you get to pick what your hardware is, Rust is fantastic. If you don't get to pick... it's a roll of the dice.
I'm only about a third of the way through the rust manual myself, so I can't say with confidence, but I suspect that rust's safe memory abstractions don't necessarily scale down to the lowest end of MCUs. The machine code instructions that make the code efficient simply may not exist on an 8-bit segmented memory CPU. That also touches on the gaps in LLVM support. I'll bet it's perfectly viable these days on any cortex-m MCU, though.
Also, a lot of embedded code consists of peripheral drivers, and in rust that likely means "unsafe" code. At that point, it's a bit of a wash which language you work in. That's especially true since rust can interoperate with the C ABI.
I haven't familiarized myself with all of rust's built-in data structures yet, and I'm not sure how much stuff necessitates allocating on a heap under the hood. That would be a compelling reason to carefully consider its use in some embedded systems. That's analogous to C++, where it's typical to avoid most of the STL data structures.
Most of Rust's memory safety comes from compile-time checks, not runtime code.
You do need some unsafe, but not as much as you may assume at first.
Rust doesn't really have any complex built-in data structures, and doesn't require a heap at all. That's a standard library thing, which you wouldn't be using in this context.
Rust on a micro is more than theoretical. You could start a commercial firmware project on it today. However it is an extremely slow-moving segment of the industry so I wouldn't expect to see much of it for a while.
For "embedded" linux grade CPUs, rust is starting to gain some practical traction. A few years ago the idea of writing application level glue code in it was still a bit silly, but these days it's starting to actually get linked into production systems. It all seems to be done in a way that's interoperable with existing C/C++ codebases, though.