even if it's not "particulary compelling" at least in difference to C/C++ it lets you sleep soundly (In my opinion from business POV using C/C++ is completely u

even if it's not "particulary compelling" at least in difference to C/C++ it lets you sleep soundly (In my opinion from business POV using C/C++ is completely unsustainable.) and in comparison to languages like Python it lets you efficiently refactor code on larger scale by having types and in difference to Java you don't have to worry about all the complications and optional parameter Java brings with it when deploying it rust isn't so successful by being the best, it is by having a different set of issue then some of the other established solutions --- > Because programmers are hyper-rational. no not at all, they love to claim so, but we are humans and the very huge majority of humans things first emotional (including here the "feeling" experience gives you) then rational in various ratios, including most people which claim they don't do so in my experience > “What the fuck are we doing in the cases where there are no vunerabilities?”. I would argue for C++ this is basically close to never the case. Else memory issues wouldn't be such a huge deal even for companies which teams mostly consists for majorly above average programmers. But outside of a few exceptions most companies have teams including average and below average skilled members. But the issue with especially C++ but also C is that it's really easy for someone who is not yet an expert to produce code which passes tests but has subtle easy to overlook UB which depending on how the compiler happens to optimize might be a security vulnerability and the status weather it is or not can even change over time without changing the bad code. Not just by changing the compiler but also by changing other code around it. So IMHO this means that from a business POV it's only reasonable to use C++ if your teams exclusively consists of only the best most disciplined programmers (and they definitely never get idk. brain fog from COVID). Which means it's basically unusable as using it is too much of a unneeded risk. (There are always exceptions where this risk can be worth it, e.g. due to existing library only available in C++.) For C things are a bit different and hope people stop lumping them together. It has much less of the hidden pitfall complexity which is perversely permeating C++. But due to the lack of abstraction code reuse can be quite a pain, and while overdoing code reuse is an issue, C is just too far behind in this aspect needing too many hacky solutions to allow you to be productive. Nothing of this means you should use Rust, but independent of Rust using C and C++ for a new project is just a pretty terrible business decision for most companies in most situations. I mean think about it ignoring Rust and languages for which it's hard to find and/or onboard developers for many server use cases Java is a better choice then C++ (sure Java as a stickma but its really no longer that bad, and for some use cases even Python can be just fine, oh and Go), for phone apps Dart (easy to use/onboard, flexible enough) or Swift(iOs)/Java(Android), on windows C# (and sometimes also on Linux). Even TypeScript is quite often a better option then either C or C++ (TS has issues, but it can be surprisingly productive). However I look at it outside of some cases mainly related to existing libraries for most companies most of the time there is just no reason to use C++ or C as there are always better choices. In the few non "existing library related" cases where non of the above mentioned languages work well Rust most times is an very viable option with the major benefit that it's much more viable to accept contributions from people not very experienced in Rust then it's with C++. So I understand if programmers which have specialized in C or C++ want to continue using it, and in turn companies might be forced to use it for employee sanctification. I also understand that there are ton's of libraries which can save many hours of work available sometimes only are nicely usable by C++ and some other more niche cases. But ignoring cases like that from a bussiness (not personal) POV using C++ or C is just a pretty bad decision. And coming back to the question why some programs don't have memory related security vulnerabilities if you ask the question industry wide the answer is often: "Because it doesn't use C/C++ but <gced or similar language> the risk of it happening was reduced". ---- One think the author seems to allude to is that many programmers need better training, teaching approaches to handling programming etc. I agree. But I strongly, disagree that this "fixes" the issues C/C++ has. It's also not really viable as long as the IT industry is expanding as fast as it did in the last 20 years. There is also the issue with Computer Science and Software Development being two different things with some overlap. But many teaching industries handle that separation badly. I'm really wondering will that get better (less expanding software industry) or worse (ChatGPT and co. making it even harder to properly learn it). Anyway training needs to change.