Considering how much of the actual programming in embedded isn't so much programming in C but metaprogramming in C preprocessor I wonder if 1:1 replacing this with another language/conditional compile pair would really be smartest move. It could be very interesting to embrace the fact that you are writing a program that writes a program instead of pretending that it's all one language. Don't hide the two-stage nature of embedded development, radically rip them apart. The first stage could be so much more than an afterthought if you elevate it from macro replacement to a type-heavy behemoth like, I don't know, a Scala DSL tailored for generating target-specific C/Rust/whatever source from a template. A template that interleaves precompilation and target language, like C source already does, but with a proper language for the first stage instead of a glorified find/replace sequence. This would have to happen in the form of cross-pollination from the web world because they have decades of learning from mistakes in markup generating code and almost half as much in dealing with the ergonomics of anything-to-js transpilers.

I suspect that if you'd separate all the customary compile time logistics into its own, distinct preparatory stage it would be much easier to get different languages from the ubiquitous "a compiler backend exists, but..." to actual pragmatic usability.

Much of embedded programming is about coping with quirky hardware and nudging bits and bytes around. And coping with rather sloppily put together tooling that requires a lot of hand-cranking.

Introducing higher level languages doesn't really solve this. If anything, it would make things worse because it would focus attention where the problem isn't. Adding lots of complexity by adding transpilers for a bunch of languages just makes things more complex and does nothing to solve the actual problems.

(Slightly orthogonal: just look at how horrid Zephyr becomes due to Python-based build tools that keep breaking things with every release. Choosing Python actually made things worse because Python brings its own unmitigated problems. It screws up your day even before you get to do any programming)

Whew. I’m glad it wasn’t just me that thought this. Zephyr devs seem really blind to this. And the swap to CMake didn’t help things.

I think something that ties in with the target language and is aware of the syntax of the target language, like Rust macros, has many advantages. At the same time I do not know enough about Rust macros yet to tell if they are really powerful enough to help here.

There are blog posts exploring some of the use cases for them, but it depends a lot on what you want to do.

https://blogs.itemis.com/en/eclipse-mita-bringing-software-d...