[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.