after some experiments with C-only and C++-only projects I have actually decided to use some mix of both for embedded programming. And actually much of it was inspired by ChibiOS
I agree, that C++ can do all the things you are looking for, Giovanni, but I also agree, that C++ code tends to become inefficient and unsafe. This becomes very obvious when students with no experience in embedded programming start to use our system. However, my opinions about these two languages are:C
- + very clean, straight forward code
- + very explicit (no surprises in the background)
- + great to maintain
- + easy to add features
- + almost everyone knows C
- + very portable (many other languages and tools feature C interfaces)
- - either unsafe (e.g. cast to void*) or inefficient (e.g. type safe wrapper/converter functions)
- - flaws in the standard (e.g. inline may or may not be inline)
- + object oriented
- + abstraction with zero overhead
- + type safe compile time stuff (templates, constexpr, etc.)
- + almost everyone knows C++
- - almost nobody knows how to use C++ for embedded
- - many features unsuitable for embedded (e.g. vtables) without good alternatives (mostly fallback to C)
- +/- most of the pros and cons of C
When talking about a new language, you should not only consider properties like safety and efficiency, but also usability - how fast can you get things done. I personally stick to clean C most of the time and I think unsafe code is acceptable as long as you know what you are doing. By enabling according compiler warnings, it is not even that risky anymore, as you are informed about implicit casts etc. For interfaces that are supposed to be used by others (who may not know what they are doing), I provide C++ classes and such. As a result, you get a fast, type safe framework, which can be used in a safe, comfortably, object oriented manner. Nevertheless, it would be great to have a language where you get both at the same time. Maybe something like "C with templates" could be close to what we are looking for. I have no experience with Rust, however, so there might be some useful features to incorporate from there as well.
When it comes to runtime safety, though, this is something that can not be solved by any language. You can analyse your code, of course, and optimize execution order or whatsoever, like Korken did in his work, but not on a language level (except maybe assembly?). If a developer wants to do messy things, a language can not stop him, and I think this is actually very important. If you want to try something new in some creative way, it would be counterproductive if the tool (the language) would prevent this. Only by allowing developers to do something wrong, they can actually do something better - something that was not considered when the language was designed.My opinion
A language such as Giovanni proposed would of course be great to guarantee safe and efficient code, but it will never be able to handle runtime checks at compile time by itself. It will furthermore limit its capabilities to the use cases that were considered at the time of its definition.
While C and C++ are probably not optimal for embedded systems (I don't know about Rust), they are quite close and they are well known. So when it comes to "being better" and "getting things done", any new language will have a hard time to rival those.
Anyway, if safety and efficiency of the resulting system is the primary goal, you should probably think about throwing away your microcontroller/SoC and use an FPGA instead. You just need some time to get used to VHDL (or something similar), take some IP cores, glue them together, spice it up with your own logic, and you are as safe and efficient as you can get (except for ASICs).
EDIT: I just remembered the D language (https://en.wikipedia.org/wiki/D_(programming_language)
). I only did some tutorials. but one of its primary goals is to calculate as much as possible at compile time, something C++ encourages but not enforces.