It's just a different world. You need cross-compiler support. Developers are spending much more time on compilers where the target is the same as the host arch

It's just a different world. You need cross-compiler support. Developers are spending much more time on compilers where the target is the same as the host architecture. Logically so! Compare GCC arm cross compiler to clang for example. The system should be expressive enough to allow you to write function pointers to specific addresses in memory. For example if you have a binary radio stack, this might be a requirement (imho callbacks are better, but yeah). With the linker this is easy as is constraining heap, stack, etc. Where do you begin with the Python VM to do the same? It's just harder. Support from the chipset manufacturer. If there is a HAL, it's in C. Good luck with a Rust crate pulled from somewhere random and keeping it all up to date. Debuggers. GDB is pretty awesome in case you really need to know what's happening. You can't debug by just writing logs if you're working on the UART implementation for example. Setting breakpoints and analysing the stack is essential. Design patterns are just different. I had a recent discussion about leaving out the destructors of a series of objects on a large mode switch (in a setup procedure) in exchange for writing the mode to FLASH, a device reset, and a few lines of startup code. The latter - the reset design paradigm - would come with a smaller binary. No management needed of all objects. A bit like rerendering the entire screen instead of only a part of it. Hence, it's not just because people are "negative". It's really a best tool for the job kind of thing. The C (eventually C++) ecosystem is that tool.