As one of the people who often make this argument, this is spot on: I continually see people who say they are spending some ridiculous amount of time actively d

As one of the people who often make this argument, this is spot on: I continually see people who say they are spending some ridiculous amount of time actively debugging memory safety issues as part of their normal development, and to me that indicates they are either an amateur or an idiot... like I just can't imagine what that must be like for them, as pretty much the only time I have to spend any serious amount of time tracking down an issue with memory corruption in my projects is when I run into some weird build system issue (which is sometimes caused by actual compiler bugs in clang/gcc that I have to painstakingly bisect and report upstream, but is sometimes an issue with an SDK or linker) that results in incorrect code being executed. I am not, under any circumstance, claiming that my software is free of bugs! I am 100% kept awake at night by the idea that someone will find a serious and exploitable mistake somewhere; but, almost by definition, that obscure issue isn't something that is taking any of my development time because, if I knew about it, I would already have fixed it and that would result in never having exploitable bugs in production software... put differently, unless you are being actively negligent, any dangerous/exploitable memory errors in your code aren't issues you are actively debugging: they are unknown sleeper issues (and then: issues which I will then claim are likely to be trivial to analyze and fix once seen). The point of using a memory safe language isn't to make your development faster: it is to make your development correct.