[staunton]

Especially with embedded applications, the issue is lack of tooling and sluggish vendors. For them, even C++ is "too new" in some cases to properly support.

Rust is making good progress despite these issues but it's still a pain to use in anything but the most common systems. As soon as you're using SoCs that have an FPGA part, for example, you're forced to use proprietary vendor tools and good luck getting Rust to work with those in the next few decades...

[cmrdporcupine]

TBH Rust in the deep embedded space -- like MCUs, not MPUs -- when I looked at it a bit ago, it was fairly dubious how much intense effort would be required to a) trim fat to get reasonable binary sizes b) keep the fat under control. I'm used to doing much of this with C++, but it seemed way easier to end up with a bloated binary in Rust <I'm looking at you, panic handler!>

Starting a job in a week which is embedded Rust, but more on the Linux-on-SoC side, we'll see it goes.

[ComputerGuru]

I do embedded development in rust on severely limited/constrained MCUs and agree with that being the biggest hurdle. There are resources to detect any panics in the resulting binary and bail as well as the compiler option to halt rather than unwind on panic. Together with a custom panic handler you can get most of that in check. Oh and you really have to compile in release mode or a profile derived from it - debug is just too damn big.

The bigger issue is that you are at the whims of llvm as to what your codegen looks like. Regressions as llvm versions are upgraded are routine and can sometimes result in significant regressions on micro benchmarks. The good news is the rust team treats these pretty seriously even if they do take time (and several versions) to get fixed but you’ll never see the issue closed out in the issue tracker. All of performance regressions, codegen bloat regressions, and llvm optimization failures (eg not stripping out a panic handler in safe rust when it should be possible to deduce that the panic cannot be reached) are all tagged and monitored and tests are often added to catch regressions once fixes land. The good news is that when you run into these in safe rust you can usually work around them with unsafe rust - unreachable_unchecked() is your best friend here and is amazingly easy to use either with an if or with a match to disavow a potential state before the code that handles it.

[steveklabnik]

I’d suspect I has to do more with familiarity than it does intrinsic differences between the two. My team does this kind of work, and it’s not difficult. It is worth tracking, paying attention to, and making changes if you’ve done something wrong, but what things cause these issues is generally pretty straightforward.