I saw a lot of fairly unstructured C in embedded programming - copied source / header files, hacked together Makefiles, lots of "works on my machine". Almost no

I saw a lot of fairly unstructured C in embedded programming - copied source / header files, hacked together Makefiles, lots of "works on my machine". Almost no abstraction to prevent use-after-free (mostly rigorous code review). I always saw that the problem it would solve is more about tooling - Rust would be a fairly good fit because it has a good cross-compilation story, and the tooling around e.g. cargo and running builds is quite good (in my opinion). The blocker right now is absolutely vendor support; no reasonable hardware company can afford to hack their own HAL without vendor support (and in fact they pay a lot for support right now, and use it). I think what these companies usually miss (good for Volvo) is that iteration time in a "higher-level language" like Rust can actually be much faster than in something like C. The setup time for a dev environment in embedded can be a week (making sure exact version match between compilers, checking out files, compiling, resolving build failures). On top of that, just having access to a language with strings and algebraic types is huge. I think there's maybe room for a Rust consultancy that could take one of the existing large manufacturers, build a toolchain around it (possibly with their blessing / support). Ferrous Systems does this (I hope there is as much demand as I am imagining).