←back to thread

11 points dacsson | 1 comments | | HN request time: 0.284s | source

I know that ~70% of embedded systems are programmed with C, lots of movement or at least motivation is seen on moving to Rust. My question is: why this languages are good for embedded software development? And overall what would constitute a good PL for this domain?
1. tliltocatl ◴[] No.43732276[source]
- One that doesn't relies on code reuse. I. e. one that isn't overly verbose. One often have to reinvent the wheel, simply because no existing library fits all the requirements - like there are three that does what I want, but one uses too much memory, another busy-waits in a separate thread eating the battery, yet another one assumes the network is perfect and panics on first packet loss. All of this works on desktop because hey who cares about power and if it hangs we can always just restart the program. Also code reuse is the primary reason why one might want dynamic allocation and this is problematic.

- A runtime that doesn't allocate silently. Read "no GC and no malloc calls from library functions". It's not just that it's not enough memory, it's when we run out of memory (and it is going to happen at some point) there will be no recourse, not even a way to log what happened if the logger itself or the log delivery mechanism needs the heap. Having "allocates memory dynamically" as a part of the type/effect signature would be nice.

- Honestly, even stack allocation is sometimes problematic. Mostly we assume it's fine, but being able to statically validate stack usage would be nice.

- What I miss in C is support for stackless coroutines. Threads are expensive because of stack size and callbacks are really painful. (In a way stackless coroutines and static stack usage are related). Zig tried but afaik didn't get it yet.

- Support for compile-time metaprogramming. Code generation sucks. C preprocessors is not nearly as bad as usually painted, X-macros are really nice, except when you make an error, you get an undecipherable mess for a message. Seriously, just having a C preprocessor with a facility "expand this token from this dictionary of macros or fail if it doesn't expand" would be much nicer.

- Well-defined integer overflows, without sacrificing expression readability. Preferably ones that would allow arbitrarily-sized intermediate results and with an operator to warp/saturate on assignment, with an optional output overflow flag. For me it's much more of an issue than memory/pointer bugs.

- Support for C interoperability (including being able to import C macros) because vendors aren't going to support anything but C ever.

Zig is quite close, through is still feels a bit rough.