[isopede]

C++ has long surpassed the point where mere mortals like me can understand it; It's so loaded with baggage, footguns, and inscrutable standards language that honestly I think the only thing keeping it going is institutional inertia and "backwards compatbility" (air quotes).

I work extensively in the embedded space and unfortunately C and C++ are still pretty much the only viable languages. I can not wait until the day rust or some other language finally supplants them.

[j-krieger]

I‘m currently doing work with Rust on Esp32 platforms and I‘ll have to say, it‘s not quite ready yet. Debug tools still have issues, and we‘re facing some problems with vendor specific magic in Esp IDF version 5.

[dlivingston]

What's stopping Rust from being used in embedded?

[isopede]

Among other things, tooling and vendor libraries. Vendor libraries are often composed of thousands upon thousands of lines of auto-generated C headers and written in some bespoke format. Demonstration code and/or sample drivers are almost invariably provided in C. Of course you _can_ rewrite these in Rust, but if you're an engineer trying to get shit working, you'd first basically have to reinvent the whole wheel just to do bringup.

I don't even want to talk about the state of proprietary vendor tooling...

[j-krieger]

Documentation is severely lacking and vendor specific libraries and build systems are sometimes interfering with cargo.

There‘s also the problem of rust-analyzer being relatively flaky in general and even more so when being used with environment specific / KConfig / build system feature flags that enable or disable certain library headers.