And embedded systems vastly outnumber classical computers. Every classical computer includes several microcontrollers, every car, modern appliance, camera, toy, etc does too. Safe languages for embedded and OSes is very important. Rust just happens to be pretty good for other use cases too, which is a nice bonus. But that means the language can't be tied to a single prescribed runtime. And that it can't have a GC, etc.
Never heard of either. You will have to expand on your reasoning. Microcontrollers do outnumber classical computers though, that is just a fact. So i don't see why there is anything to disagree about there. Even GPUs have helper microcontrollers for thermal management and other functions.
They have been selling real time bare metal Java runtimes for embedded systems, widely deployed across weapon systems in battleships and missile tracking units, factory automation, satellites, and other similar systems for the last decades.
I bet many of those helper microcontrollers, are still Assembly, compiler specific C, and if there is Rust support, most likely only no_std fits, thus no async anyway.
Java on smartcard etc is a thing. I haven't met anyone who used that and actually like it. And it is apparently nothing like normal java.
Many microcontrollers are indeed still running C, but things are starting to change. Esperif has official support for Rust for example, and other vendors are experimenting with that too. Many other microcontrollers have good community support.
> if there is Rust support, most likely only no_std fits, thus no async anyway.
This is just plain incorrect. The beauty of async in rust is that it does work on no_std. You don't need an allocator even to use Embassy. Instead becuause async tasks are perfectly sized, you can reserve space statically at compile time, you just need to specify with an attribute how many concurrent instances of a given task should be supported.
PTC and Aicas aren't Java on smartcards, they are Java on high integrity computing where human lives might be at stake.
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.
> 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.
