Thank you for a thoughtful response. I do hope I am wrong and we as an industry end up in a better spot overall, though I suspect Rust is not the language that's going to get us there. Most accounts I've read or conversations I've had with people who used Rust in large projects boil down to "it's not worth fighting the language", so my general impression is that Rust is the Perl of this decade, and I'm excited for the next generation of languages after Rust, because they will have to consider the safety aspect.
In the three projects I've been on that used rust, there really hasn't been much of that. Mostly I have been surprised at how high level it feels even with all the control. I do think the type of project makes a difference. I have been doing mostly dsp type stuff. And coming at it from the mindset of ocaml or modern c++ (value semantics etc.) Vs the ansi c mindset I used on TI DSPs back in the day makes a big difference. And that is the problem with bolting on the safety. The borrow checker doesn't just find mistakes, it also forces you to code in a different style so it can reliabily do so. Not necessarily a better style, but not slower either, a different and easier style for it to check. The syntax could have been closer to c, but the style would end up being similar. As far as all the complexity getting added, ferrocene or someone like them may end up making a safety critical subset like spark is to ada, that is simpler to do formal verification on. That would be a good subset for drivers and kernels.
