> Interesting how compiler specific extensions are ok for C, with a freestanding subset, or Rust no_std, but when it goes to other languages it is no longer the same.

Not sure what you mean here. For Rust there is only one de facto compiler currently, though work is ongoing on gccrs (not to be confused with rustc_codegen_gcc, which only replaces the llvm backend but keeps the rest of the compiler the same). Work is also ongoing on an official spec. But as it currently stands there are no compiler specific extensions.

If you meant the attribute I mentioned for embassy? That is just processed by a rust proc-macro, similar to derives with serde is used to generate (de)serialisation code. It too adds custom attributes on members.

It means that being constrained to C compiler dialect for tiny CPUs instead of ISO C proper, or being constrained to [no_std] instead of the whole Rust capabilities and ecosystem, isn't seen under the same light as when it is C++, Swift, Go, Java or whatever else might also be constrained for the same purpose.

Hm, I haven't come across such sentiment. It is fairly well understood that if you use C++ for example on embedded, you are limited as to what features you can use. I remember coming across that when using PlatformIO for Arduino many years ago, certain parts of STL was just missing.

The other languages you mentioned I have no personal experience of in embedded (and hardly outside embedded either), but I understand they are less common (apart from Java possibly, but only in certain niches). There is also Ada/SPARK and MicroPython (which always seemed more like an educational thing for people new to programming). I haven't used either.

I would like to add that it feels like no-std rust is less constrained than freestanding C to me. I haven't managed to figure out why exactly. Perhaps the ecosystem of crates in Rust for embedded is just better, with many crates offering a way to opt out of the std-parts (plus a number of good libraries aimed directly at no-std). Perhaps it is that it is easy to add alloc to no-std if you are working on a higher end embedded system (with obvious tradeoffs in code size, memory usage etc). Or perhaps the no-std parts of rust simply contains more than freestanding C.