4 ms·

I work in embedded software for network switches and almost everything is written in C. And most of the code is pretty new. C++ fired back because integration

I work in embedded software for network switches and almost everything is written in C. And most of the code is pretty new. C++ fired back because integration was ugly (the SDKs are designed for C usage) and a lot of C developers that doesn't understand C++ well. Go is used a bit, but again, training people for using it correctly is hard. And using the C SDK from Go is an obvious NO. A lot there think that Rust would be in a similar situation that C++. Nice to have, but too much low level dependencies (hardware SDK) and high level (developers proficient in the language) to expect it to happen. Also, calling the SDK would convert everything I'm unsafe, so we are like in C, but with a language that nobody understands. So, there are technical reasons, but also human resources and economic ones.

tempodox 6y ago
Yep, embedded is a whole other area than software that runs on a server host or desktop/laptop workstation. That shouldn't stop us though from improving safety where the restrictions of embedded development don't apply.
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.
mov_ 6y ago
I work on network switches too, but we take the C SDK source, reverse engineer it, and write a bunch of C++ software that mostly does the same exact thing. It's already insane, I would not be surprised if some Rust components were added.

tempodox 6y ago

Yep, embedded is a whole other area than software that runs on a server host or desktop/laptop workstation. That shouldn't stop us though from improving safety where the restrictions of embedded development don't apply.

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.

mov_ 6y ago

I work on network switches too, but we take the C SDK source, reverse engineer it, and write a bunch of C++ software that mostly does the same exact thing. It's already insane, I would not be surprised if some Rust components were added.