I'm really surprised at how stable and widely supported Rust's FFI is.
I have several C++ projects that integrate a portion written in Rust, where the Rust project produces a .a file that is ultimately linked with clang into a larger C++ project.
I definitely agree Rust has a long road to adoption in embedded/low level systems, and particularly areas with custom compilers/toolchains that rely heavily on system specific undefined behavior.
But it's a lot closer than I had thought it was a year or so ago.
I agree. But I think it'll be hard to see Rust really make progress until hardware makers worldwide start really doing 'Rust First'. And the problem there, is that Rust is a bit inaccessible to many.
Rust trades of absolutely everything for performance - and that's just not the trade-off we want to make in most scenarios. Even for most embedded systems - something that's easy to program, easy to read, easy to support, great tooling etc. is worth more than a 'a bit faster performance'.
If we were to have created something ideal for embedded systems, it would not be Rust. I think it'd be a bit more like Go. Or just like a 'Safe C' with a lot better built-in libraries.
I like Rust but I fear it is not 'the one' and the bandwagon has already left the station so we have to go with it.
And of course, Python is much more broadly applicable.
I don't like to develop in C++ because it's a tiresome mess of issues that don't exist in modern languages.
I don't care about the newer variations or whatever, I still can't do basic things or pull in a library to do it 20 years later so no thanks.
That said - it's not going to go away.
While Rust is nice, I just don't see it replacing C/C++ for a long time due to abi incompatibility etc..
C++ does require more experience, and it needs to pay well or companies won't get the talent.