Even if the code is flawless now, all it takes is a single flawed line of new code. This is of course true for all languages, but type safety helps a lot as some types of flaws would not compile.

I loved python when I was a junior dev. Now I hate it (except for things like computational math). I have to add debug statements to figure out that someone snuck in the wrong type into the code.

Hell, assembly code is still necessary for the lowest-level init code. Once you have a functional stack and some var init logic you can graduate to C.

In my corner of the embedded world, it feels like everyone is practically jumping to integrate Rust. In the sense that vendors which haven't had to innovate for 10+ years will suddenly publish a Rust API out of the blue. And I'm saying "out of the blue", but I do also regularly hear from other devs, that they've been pestering the vendors to provide a Rust API or even started writing own wrappers for their C APIs.

And while it's certainly a factor that Rust is good, in my experience they generally just want to get away from C. Even our management is well aware that C is a liability.

I guess, I should add that while I say "jumping", this is the embedded world where everything moves extremely slowly, so we're talking about a multi-year jump. In our field, you need to get certifications for your toolchain and code quality, for example, so lots of work is necessary to formalize all of that.

I've been an embedded developer for coming up on 20 years at this point, and recently went through a job hunt. Of the three that made it to the offer stage, two used Rust almost exclusively in their embedded stack and one used Rust in their embedded LInux stack and was trying to decide if they were going to use rust in their bare-metal/RTOS stack. I ended up at on of the Rust places, though I had no Rust experience. I have to say, while I do find many parts of the syntax too cute by half, in general I'm pretty happy with it as an embedded language. My current target architectures are ARM Cortex-M7 and Cortex-A53. In general toolchain, and debugger support has been good, peripheral support has been ok but could use improvement.

It's not widely used. Some car manufacturers(Toyota if I remember correctly) have started testing it. Some parts are really nice.

There is exactly one hal for i2c, spi and Io pins. As long as both your chip and peripheral driver implement against it, it just works. There are more unified abstractions in the work for things like DMA, but they are not officially stable yet.

Cooperative Multi threading can easily be integrated thanks to Async rust and executors like embassy.

All the crates that are no_std compatible can be included.

It's not perfect, but it's getting there.

Also, like, fuck golang, it’s such a shit language and the compiler does very little to protect you

I never understood why people like it. It's a "new" language, and it still doesn't seem to get the basics right. No proper null handling, and don't get me started on interface{}. It's like they set out to build a better alternative to C++ while ignoring the other developments outside C/C++ for the past 15 years. The compiler is damn quick, though.

Skill issue

- sincerely, someone making a DST crate

EDIT: To clarify...

There are some things that are only doable on nightly Rust (like specialization, const fn in traits, etc.) and the reason for that is to avoid future issues. In that regard, Rust will not be as good as C++... at least until those get stabilized.

Some of the nightly functionality (like ptr_metadata) can be achieved with unsafe code and it's fine to do that, as long as it's only done when necessary and it's properly documented.

It's okay to want to use C++, but that language has it's own issues and footguns (virtual destructors, "move semantics", C-style casts, header files and more) that Rust wants to avoid.

EDIT 2: Specialization is also kinda doable with deref coercion, but that's another can of worms I don't wanna open here.

EDIT 3: And if I had to mention some of Rust's footguns:

• unwrap panics, which isn't bad in and of itself, but it's short so you'll probably want to use it instead of other error handling methods (see recent Cloudflare outages)
• unsafe functions implicitly allows using unsafe operations (fixable by adding #! [deny(unsafe_op_in_unsafe_fn)])