There seems to be a common misconception here amongst traditional desktop and server software people that embedded programming requires vast software complexity. In fact, most real world electronics are very simple software wise. There's just a lot of them, they're a pain to get to, and they have alternative and nuanced challenges and context (cost, speed, debugging, stability, environmental considerations, etc.).

Now regarding language, let me illustrate an area in which C/C++ sucks balls for embedded. Using a cheap MCU is generally considered good practice if you have many target systems to produce and they are possible to execute on that cheap MCU, because using a pricier one will quickly add up and retargeting a team costs a lot. The problem is that on a cheap MCU sometimes you run out of basic resources, such as physical interfaces (pins). In the embedded world there are multiple solutions to most problems, just as there are in the conventional software one (ie. classic perl quote TMTOWTDI) and one of these is connecting IO expansion chips via alternate (particularly shareable) interfaces such as I2C/SPI. Such chips provide various types of interfaces by proxy, for example additional GPIO pins. The issue with these is that many libraries, such as those written to control motors, those written to control MOSFETs/relays, those written to control serial devices will not work by default on these proxied interfaces. Therefore, you need to either hack or rewrite the respective libraries in order to use them.

Coming from a software background myself, this is a basic interface abstraction, and the current solution is ridiculous. Reflectance would go a long way to solving the issue. Lua frankly appeals more than Rust in this regard when dealing with third party, existing libraries which were not constructed explicitly with the requisite abstraction. Alternatively, I believe some software people here on HN recently announced they are attempting a generative approach for embedded circuits and software, sort of a 'ruby on rails' shake-n-bake approach to the whole problem space. The issue with such approaches tends to be that you wind up with a whole lot of deployable product but nobody who understands the intricacies, a vast cognitive overhead for your higher level generation specification languages, there are frequently incompatibilities in devices which are based upon timing, clock frequency or other hard to model aspects of a proposed system, and iterations in hardware cost a lot more in time and money than those in software. Both approaches are used in embedded development, but it is a vast space whose tooling usually differs by target hardware, as if you needed a new IDE, compiler, command line, development workflow and physical interface type for every language you wanted to write on a desktop, and interpreted languages didn't exist. Some of the tooling is prohibitively expensive.

I hope you can now see the problem space is not that similar to desktop software, although the conventional software world does have a lot it could further contribute to electronics. As usual for those outside of an area, the perceived simplicity of established solutions belies the complexity, nuance and outright effectiveness of their current, if ugly, state.