Google says replacing C/C++ in firmware with Rust is easy

> Google was already sold on the idea, having concluded that its Rust developers are twice as productive as its C++ engineers.

Not so. The actual study compared the cost of writing something in C++ to the cost of porting it to Rust.

As someone who writes, reviews, and maintains lots of C code professionally, here’s what I think a lot of Rust advocates don’t understand: We see and understand the benefits of Rust. That’s no longer something we need to be sold on. Every C programmer who’s written and reviewed any amount of nontrivial C code likely has firsthand experience dealing with memory safety bugs that would simply disappear with a memory-safe language.

The ultimate problem is that most of the muscle memory you’ve built using C over the years becomes useless when writing Rust due to so many of the semantic differences. If you were an expert and highly productive C programmer, your productivity will go out the window for what feels like a long time until you feel even just comfortable writing Rust. That makes Rust a very hard sell for C programmers who simply want to get things done. This is an area, by the way, that I think Zig does extremely well at—it provides safer semantics (despite its lack of guaranteed memory safety à la Rust) in a rather simple language and without rendering so much of your experience useless.

Rust is interesting but still has some pain points.

- Compile times. This, above all else.

- As an embedded dev: no_std is still rough around the edges, which the original Google blog post captured pretty well. They didn’t talk about PACs - the PAC paradigm also feels needlessly complicated - whoever wrote it really loves their zero-sized types and made it verbose to the point where the solution feels worse than the problem (at least to me) for things like using GPIO lines.

- Rust has a history of shipping serious bugs (see, floating point recently), and you basically have to constantly update your rust version. Not ideal for commercial products, which want stability.

- All of the RTOS options are also young. None of the major existing ones (e.x. FreeRTOS) support Rust natively. You’re not just asking people to learn the language, but start over on libraries and platform as well.

- The community is weird. If you don’t drink the koolaid you will be attacked.

Rust is constantly getting better, and the pain points of C impact real peoples lives in very real ways (security bugs that have led to people truly getting hurt), so Rust feels inevitable, but it’s still early days and pain.

I just can't bring myself to spend time learning Rust when all the demand is for C++, C, Java, Typescript, Python, etc. Feels like we're going to be stuck in this limbo forever similar to languages like Kotlin.

Android engineers don't really speak for the whole of Google

Not surprised, rarely is it worth rewriting an entire codebase though.

Not sure who would do that or what the implications might be for replacing all the say Python code with cpp.

Original source: https://news.ycombinator.com/item?id=41458508

(not a judgement, just an observation) Google, the conglomerate with the resources to bless us with Go and Kubernetes; another language and a container orchestration platform created with it. Their easy isn't my easy.

You would think distributing firmware and flashing would be routine; several vendors have shown me it isn't

All this talk is pointless. The DoD is what will incentivize people to finally make the switch permanent. You want the real funds, you’re gonna have to write in a memory safe language going forward. At least that’s what the US government says.