2 ms·

Yeah, I see the same problem with C and C++ in embedding, too. My guess is that people in embedding were working originally in low-level language like assembly

Yeah, I see the same problem with C and C++ in embedding, too. My guess is that people in embedding were working originally in low-level language like assembly where types don’t exist (at least that's what I did with the PIC and older AVR microcontrollers). So when they introduced higher level languages such as C into it, they did it in an assembly-like fashion and not truly in the spirit of high level languages. For example macros are still extensively used for definition of a lot of things, including IO-pins, and they undergo no type checking. C is not a strong -typed language anyway and this mode of thinking and programming continues to spill-over when C++ was introduced. Type is used merely to limit memory allocation and ensure memory alignment, not truly used in its conceptual sense. Of course, the resource constraints and efficiency of the compiled code play a significant role here. So unless a new memory efficient strict-typed language/compiler comes along with a modern mindset, the power of type will not come into play.

darksaints 2y ago
The last time I used Rust for any sort of project was two years ago, and the code size concerns were one of the first things I thought about when contemplating writing for embedded targets in Rust. Executable sizes were really bad, especially at -O1 optimization levels, but I haven't really seen much of a problem in practice today so maybe they fixed it. From a performance and memory efficiency standpoint, Rust is on par with the C/C++ projects I've worked with. Some things slightly worse, some things slightly better, but nothing egregious in either direction. I will say that the coroutine-based async facilities in Rust's embedded-hal and embassy-rs projects make task-based concurrency so easy to do with bare-metal code that there isn't much need to use an RTOS in many of the situations that a C/C++ project could do. That sort of OS-less concurrency is no doubt possible in C, but I shudder to think what it would look like.

darksaints 2y ago

The last time I used Rust for any sort of project was two years ago, and the code size concerns were one of the first things I thought about when contemplating writing for embedded targets in Rust. Executable sizes were really bad, especially at -O1 optimization levels, but I haven't really seen much of a problem in practice today so maybe they fixed it. From a performance and memory efficiency standpoint, Rust is on par with the C/C++ projects I've worked with. Some things slightly worse, some things slightly better, but nothing egregious in either direction. I will say that the coroutine-based async facilities in Rust's embedded-hal and embassy-rs projects make task-based concurrency so easy to do with bare-metal code that there isn't much need to use an RTOS in many of the situations that a C/C++ project could do. That sort of OS-less concurrency is no doubt possible in C, but I shudder to think what it would look like.