I would love to be able to use something like Rust, but the RTOS options and library support are not quite there yet.
With more powerful embedded processors becoming available, Micropython is an option for some projects.
I'm using ESP32-S3 chips in a project. Rust support is really nascent and I can't afford to burn too much time on fixing tooling & recreating libraries. Though it does sound kinda fun.
But I imagine there's a chicken/egg challenge where it's hard to see Rust on embedded platforms get more mature unless it gets more adoption and it's hard to imagine a significant uptick in adoption unless it gets more mature.
Modern C++ is getting a little better all the time. And perhaps someday Carbon could be a smoother path to modernity because of its focus on migrating existing c++ codebases.
Honestly, this is the reason I haven't moved anything to Rust, despite seriously considering it in the past. I would ditch C++03 in a heartbeat, but C++14 and beyond are very usable.
C++ could certainly be better - I'm hopeful about Carbon - but it's good enough and improving fast enough that if you're already a C++ expert, I think you're pretty happy.
(Bonus points: Declare a static constexpr value in a compilation unit... and use it somewhere at runtime to get the moral equivalent of consteval for the values you care about.)
Functionality appears to be increasing fairly rapidly though, so I might take another look soon.
Stack sizing is hard. Stack swapping kills caches. Stack overflows can be very infrequent and hard to debug. Thread priority doesnt always do what you think. Even with threads not every RTOS does time slicing.
So right is there a complete network/usb/ble stack in rust today? Not that I’ve seen. So I can understand needing those and thinking maybe it’s not quite there. I do think though that some really interesting and cool ideas on scheduling, device Hal’s, and state machinery has been pretty well explored at this point. It’s still young but evolving and maturing quickly.
Rust's ecosystem still struggles with no_std, so the majority of crates won't work. Worse (for me) is that using Rust with arrays (not heap allocated vec's) is still a pain.
Nim compiles to C or C++ so its easy to use on any embedded platform and compiler suite. Thats still huge for embedded. Rust forces a type-trait centric programming style which makes interfacing hardware/embedded harder as you have to make type heavy HALs everywhere -- hence the lack of rtos & library support despite its relative popularity).
Its pretty trivial to re-use any C/C++ libraries which gives a big boost to the native ecosystem. I wrapped most of the esp32 idf in a few weeks: https://github.com/elcritch/nesper
The new GC (ARC) is basically a built in `shared_ptr<T>` or `Rc<T>`. You can also do stack-based programming too and the compiler enforces a safe memory accesses. The performance is great and can match or beat C/C++ if you do a few hours of tuning. Though its easy kill performance if you're lazy (e.g. parse json into a bunch of heaps objects), but that can have its place.
There is always a compiler available from the manufacturer, and often a gcc target.
The AVR family of processors, for example, are supported by the manufacturer's IAR compiler, the ImageCraft ICCAVR compiler, AVR-GCC and several others. IAR produces the fastest / most compact code in many scenarios, but costs $thousands. The ICCAVR compiler and IDE is much cheaper and preferred by many developers. Personally, I tend to avoid pushing the limits of a processor, so the GCC toolchain is most often good enough.