> I don't think it's impossible that in another 10 or 20 years C and C++ engineering roles will become much better paid as legacy code maintainers' pool will dry up.

Maybe. I've made the jump from pure embedded (spent over 15 years in embedded) to backend (Go, with some rudimentary Java thrown into the mix). I literally doubled my salary in the space of 12 months.

In 20 years, are they going to hire my retired old ass to make their codebase live another 5 years longer, or will they simply bite the bullet and rewrite?

> Hopefully as a result of moving to languages like Rust - it would work out best for all developers.

It could happen, but I'm not that bullish on that happening:

1. No benefit - The very low-level embedded systems that toggles signals on wires doesn't gain much, if anything, from memory safety[1] - the end result of using Rust on a 2kb RAM/8MHz chip (atmega328, or xmega, or one of the stm32s, for example) is going to be using unsafe everywhere anyway.

2. High rampup - the majority of knowledge needed for low-level comes from EE, not CS. Already Rust has problems with adoption amongst CS people, who (in theory anyway) have all the requisite knowledge and motivation to climb the learning curve. I'd bet money that EEs won't even bother looking beyond the awful syntax.

3. Better alternatives - all those higher-level embedded projects such as RPi, Beaglebone, etc that run Linux have better alternatives for programming them than Rust. Most custom code written for the RPi is in Python, for example. Someone looking to develop on these boards is almost certainly better off using Go instead of Python, and Python instead of Rust.

So given that there's a) no benefit on low-powered devices, b) there's better alternatives on high-powered devices and c) it's a complicated language with slow ramp-up, I'm having trouble in seeing exactly where it fits in for embedded.

> But it's not looking good in the C++ land salary-wise now.

Nope, it isn't. If enough C++ devs jump ship (and, to be honest, in low-level embedded C++ as you know it isn't used much anyway), then salaries will rise again.

The problem is, as someone else pointed out, that many of the places using C++ are shooting themselves in the foot, because they want senior and experienced people who can ramp up quickly on the latest C++ standard, but without a pipeline of unskilled/juniors, there's only a few number of years before there'd be out of any C++ devs.

And because it's not an attractive language, there's no one switching from (for example) Java to C++, or C# to C++, while there are plenty switching from C++ to Java or C#.

[1] Beyond which, it is not clear if safe Rust will ever be able to interact with various embedded OSes for these chips; most of them are external kernels anyway, so there is no way to use those kernels without using C.

The only place I can see Rust (or Nim, in our case, mainly so we can easily wire in existing C libraries and vendor provided drivers) in embedded land are the “in betweeners” or “crossover” chips — ESP32-S3, some of the i.MX SOCs, that sort of thing.

Where they have enough grunt to do a lot of tasks at the same time, all driven by config over the network, with less hard real-time requirements for some tasks and stronger requirements for others.

That’s not that big a segment though, I would think. And in some ways, just chucking extra slower chips at the problem on the same board is simpler.

> No benefit - The very low-level embedded systems that toggles signals on wires doesn't gain much, if anything, from memory safety

The Rust embedded ecosystem has lots of benefits in addition to pure memory safety, which is basically table stakes for a modern language. It gives you a vastly improved DevX, at least if you aren't using hardware that's too exotic for which only proprietary C/C++ toolchains are available.