[backslash_16]

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.

[steveklabnik]

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.

[backslash_16]

Thanks for the great and clear explanation, it makes more sense now! (a lot more sense)

I didn’t know that Rust support for a LLVM target isn’t free and didn’t realize micro-controller targets are so diverse. Very cool.

[sgtnoodle]

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.

[steveklabnik]

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.