[RaleyField]

> but I've done more of a decade with C++

So have people at Mozilla (or people anywhere else) and there are still horrible bugs in Firefox or other similarly large projects.

> is too complicated for what you get

If you aren't convinced by arguments that safety is intrinsically valuable for yourself or your customers then another argument is that with safer languages you pay the price upfront (i.e. learning and programming with what seems a more complex language) instead of later spending weeks or months on catching a bug causing crashes.

[lkiux]

I'm absolutely for safety and compile-time assurance. I wrote I've actually use ATS in embedded systems where I could to perform compile-time theorem proving. I used ATS, for example, to actually prove at compile-time the runtime heap memory requirements. This is not easy.

Rust is not on the front of research here, although the borrow checker is more pleasant to use compared to /many/ other implementations.

Memory safety is, of course, important, but security as a whole is so much more than just pointer dereferencing and lifetime checking. We got pretty far with C++, modern toolchains and OS support. Rust programs will be only marginally more secure by default than other classes of programs. Rust will not help with entire classes of other problems like side-channel attacks, any logical bug (like incorrect initialization of IVs, unchecked reflection), and so on.

Rust helps, and I do not criticize that. But as with any system, you have to evaluate it as a whole. Is it a big boost coming from C? Absolutely. C++? Not so much. Heck, you can use LuaJIT in embedded systems, and Rust has zero advantage there.

[soulbadguy]

A bit of a strawman argument here.