2 ms·
Ultimately I think the switch would pay off for most companies in the medium to long term. There are valid reason C is still the primary embedded development la
by elcritch 6y ago
Ultimately I think the switch would pay off for most companies in the medium to long term. There are valid reason C is still the primary embedded development language but many are going away. One is that Rust only uses clang/llvm which doesn't support many targets. Still there are so many low level data races and challenges with embedded development that having a Rust environment would be a huge improvement, IMHO. The C / FreeRTOS project I’ve been using lately has random data races in the LwIP library which reset the device. It’s almost impossible for me to debug so I workaround by adding some delays here and there. C++ wouldn’t help resolve data races so it's just an extra cost. Also C++ exceptions on embedded are tricky, so the Rust error handling has closer semantics to C error handling.
A complete Rust system would likely help solve most of these issues and drastically reduce these bugs, increasing development speed. Unfortunately the lack of native SDK in Rust is annoying, but some groups are making progress on STM and no-lib Rust. It’d be great if STM makers adopted their sdk and made an official one!
Currently since Rust doesn’t support my chip, I’m using Nim to generate C. It doesn’t solve all the data races noted above but having generics and easy data structures like tables and vectors is fantastic and I'm not second guessing the code all the time. A deterministic GC covers my memory usages fine.