"For starters, all C++ sequence containers implement .at(), which is bounds-checked." Why is that the safe one and not operator[]() ??
"both C11 and C++11 support threads." But the compiler still cannot tell whether you accidentally use some global data structures or not.
"Even C++ (which implements those concepts) is deemed unworthy" I also deem it unworthy, but for the reason that it is a portable assembler with very little compile and runtime checking as compared to other languages
"I try avoid anything written in Java as much as possible." I do so, too and my posts are not meant to promote Java. Rather, something like a hardened Ada with Destructors. Or something like I did myself: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fsappeurcompiler%2F

Yes: "Well designed equipment today is much safer ... reality that industrial accidents are everyone's problem. The resulting disabilities are a tax on society."
Yes. "The argument that safety is futile and no effort should be made to improve it is the voice of laziness"
No: "A remote code execution exploit is a serious matter and should be accounted for in business decisions while calculating risk avoidance. "
How the heck can you calculate the financial loss from malware inside your network ? It might range from the mundane to the destruction of the company, if a capable, cheaper-cost-base competitor gets the complete crown jewels.
Also, you are regurgitating the Beancounter/MBA Fallacy "what you cannot quantify you cannot understand and change". We all go great lengths in terms of hygiene and use of condoms, without anybody calculating the "financial loss" from AIDS or the plague. We know it is horrible and we spend serious effort (e.g. daily dishwashing) to make sure we don't get the diseases.

Yes: "Well designed equipment today is much safer ... reality that industrial accidents are everyone's problem. The resulting disabilities are a tax on society." Yes. "The argument that safety is futile and no effort should be made to improve it is the voice of laziness" No: "A remote code execution exploit is a serious matter and should be accounted for in business decisions while calculating risk avoidance. " How the heck can you calculate the financial loss from malware inside your network ? It might range from the mundane to the destruction of the company, if a capable, cheaper-cost-base competitor gets the complete crown jewels. Also, you are regurgitating the Beancounter/MBA Fallacy "what you cannot quantify you cannot understand and change". We all go great lengths in terms of hygiene and use of condoms, without anybody calculating the "financial loss" from AIDS or the plague. We know it is horrible and we spend serious effort (e.g. daily dishwashing) to make sure we don't get the diseases. Also, I find it completely impossible to quantify the losses from an exploitable weakness. There are too many variables inside and outside your company to make a proper statement. All we can say is "damage might be from zero to complete financial destruction of company". Of course, you might make a more detailed statement if the exploit only matters in a specific department (e.g. only accounting uses Windows and the exploit). But still, how can you properly quantify your financial details being in the hands of your asian competitor ??

Maybe that is because some people don't want to waste time with these buggy, bloated and slow monsters you probably prefer. vi simply works and doesn't randomly crash every couple of hours like VS.

but have you ever seen a manager sitting down with his most experienced software developers and system admins and tell them "let's design a security policy which is both effective and acceptable to end-users" ? Surely they shell out lots of money on IT, but all the reasoning related to security risks boil down to "we are a business and we these twenty-five plugins installed on all corporate PCs". Convenience trumps security any time, in my experience. Security is definitely not managed - it is considered a nuisance and something not really worth bothering about. A "chief security officer" will be appointed and then the subject will be ignored, when the rational thing to do would be more user education and designing security policies and processes in a way that integrate into the business processes. As opposed to obstructing them and then being circumvented by users. The underlying reason for that sad reality is a lack of management attention and serious desire to improve that aspect of the business.

...is that every C++ programmer thinks he is writing "robust" code and that array bounds, safe pointers and so on are not necessary in their case. Because they are so special, of course. Reality is, people make mistakes in anything non-trivial and the bad guys will exploit these mistakes. And that includes things like the Linux kernel and Google Chrome. I don't know the situation with ::std::string, but ::std::vector::operator[]() does not check bounds and it is used millions of times in real-world code. So the STL promotes unsafe-by-default programming. Finally, C and C++ do have no proper concept of multi-threading and there are probably millions of race-condition problems waiting out there to be exploited by the Russkies and Chinese.

"avoid buffer overruns you have to do bounds-checks at run-time. But these are very expensive." In the real world, this creates a runtime overhead of about 10 to 20%. Hardly an issue compared to the security costs of a successful penetration

It is not about freedom, but about the egregious laziness, ignorance and anti-professionalism on the side of the "management talent". These people are happy so spend fortunes on lawyers and to listen for hours to lawyers, but they think it professionals should better be ignored.

That's vastly more secure than CAD workstations.

A properly failing program is vastly more secure than one which will open the gates to the confidential database. A proper exception stacktrace can usually be used to fix programming errors. Your post is actually demonstrating your security saviness. Proper programs do not "catch exceptions by random code". Unexpected exceptions should terminate the thread or maybe the whole process, depending on the circumstances. And that is the default behaviour.

The high-level ideas of Java are sound, but the implementation (or "execution" in manager-speak) has been, and still is, awful. So awful that it is now considered a security risk to have Java Web Start enabled in browsers. I also managed to crash a JVM (about a year ago) by running a PDF parser on the JVM. I am quite confident a properly crafted PDF could have taken over my user id. So, in practice, Java is highly dangerous.

Ada in Aerospace (where crashes actually kill humans) and Pascal in the Delphi RAD business, which is still there.

C#, Java, C++, Ada, Pascal will do