Why you should, actually, rewrite some of it in Rust

> The reasons provided by this article are insufficient to solely justify a re-write in Rust;

You didn't read the article. He acknowledged that the hyperbolic calls to "IMMEDIATELY REWRITE EVERYTHING IN RUST!!1!!1one" are silly. In bold, the author states:

> What I’m advocating for is much simpler: surgically replace weaker parts but keep most of the project intact.

Which, by the way, is exactly how Mozilla is applying Rust-written rewrites to Firefox (dogfooding their own programming language).

Good idea. We've added that bit above.

> I did not deny that Rust is an interesting option if automatic memory management is not a viable approach.

I think this is the main niche in which Rust can compete, while of course rust community want to attract people with different backgrounds (eg pythonists, webdevelopers etc).

It's like you say, if I don't need the performance or I am not memory constrained then I will just use GC'd language.

[edit: ah, potentially my best argument regarding UB, that I thought of in another reply in this thread: so, please tell me now, have you read all the fragments of The ISO C++ Standard regarding UB? Because if not, you by definition don't know when you may be committing UB! :) And what I can tell you, is that I have not read all of them, but I have read enough of them to raise hair on my back and make me absolutely doubt all C++ code I've ever written, or would possibly ever write in future.]

Please note I didn't say a word about Rust here :) That's your overinterpretation. First of all, I never actually used Rust; from what I've seen, I feel it has some potential and good ideas; but OTOH, I also get the feeling that one is forced to use 'unsafe' blocks from time to time anyway, so there's still some area for self-inflicted danger. Even standard library has some errors found from time to time and reaching the news. Also the compiler is new so not very much battle proven yet. Also I'm somewhat uneasy about the fact, that Rust seems to be quite a big language already, and still growing in complexity. Not sure what's the solution. But C++, as it is now, in my opinion is most certainly not one.

I was employed in a big corporation and working on a moderately big C++ codebase. It totally had UB, overwriting random memory, exceptions, etc. It was common knowledge in the operations that the app crashes randomly lots of times a day and has to be restarted automatically, to the point of this being considered non-issue. Virtual inheritance was avoided; don't recall non-public. Pointers to members, suppose yes. Templates - oh, tons of them, and growing. The company actually has super smart C++ programmers (and I mean it!), submitting proposals to the C++ committee and having them accepted. Now, note the Brian Kernighan's quote about debugging clever code. I once debugged a somewhat more -often-than-normal crash. It ended up proving to be a data race. It was a fun experience, though at times totally depressing. UBs were so common during this debugging that I simply ignored them, or I'd go insane. But when I look at how easy it is to detect and debug races in Go, and how still I have to be careful to avoid races there, and still make them from time to time, I know there are tons of them sleeping undetected in any multithreaded C++ code. And we had valgrind etc (though it was rarely used, as it slowed the app to a crawl). Now, all the perfect "modern" or "subset" C++ you claim is so flawless (for whatever actual definition of "modern" you'd try to choose) is never fully enforceable, because it would be too strict or "not performant". Plain ugly non-modern C++ will spill, I don't believe you'll avoid it in any corporate environment. Maybe in an idealized open-source side project, in theory.

As to rm, bash, zsh, Windows Explorer's right click, etc - I'm sure they are broken! Those are the so called "bugs" you hear about so often. I didn't once say I won't use those tools. I only wish they weren't so buggy and unreliable... On the other hand, worth to note that there's always a random cosmic ray from time to time, or a bug in processor's microcode. So even Rust or Idris may not protect you at all time, I suppose plain old asserts may be more reliable as a last line of defence.

And back to your first point: again, "you have to delete ASAP" is a strawman from you here. But anyway, Windows totally has tons of security bugs, see all the NSA exploits, recent ransomware, Pwn2Own, etc. Though they seem to have gradually learned since the Win95 and XP days and stuff is slowly improving. Linux, absolutely has bugs and security holes! Linus is famously not treating security holes as serious bugs, isn't he. Filesystems are buggy as hell! SQL database engines have to go to great lengths to try guaranteeing atomicity and reliability of writes over existing filesystems. Drivers, woohoo, those are especially famous for being buggy and of low quality standards, on whatever OS you like. But I never said to not use them. But you can't stop me from wishing and hoping we have them safer and more reliable some day. And maybe hopefully helping to do that too. Stuff like OpenRISC, seL4, GenodeOS (C++! that part makes me uneasy actually, unfortunately), Nix (again C++), maybe even QubesOS, give me some glimmer of hope for a more reliable future.

For serious exception safety, you have to be able to prove that all invariants all the code of your class relies on are kept between every 2 subsequent lines of your code in that class. Because exception can occur everywhere. And actually, I oversimplified, because often you must also know what happens in each and every operator you use, including implicit casting operators, and also in your destructors and constructors, including implicit ones. Each of those may or may not throw, and each of those may have some internal state, or modify your state in unexpected ways during an exception. RAII gives you primitives which you trust are written with exception safety w.r.t. their inner invariants. But you build some code on it, which has its own invariants. Do you prove them between every 2 lines of your code every time you change a line in your code? After I read enough about exception safety, I realized how hard it is to keep watertightly.