Why the case for Rust is not particularly compelling

The case for Rust is not only memory safety, but also unexpected state mutation safety, as well as multi-threaded programming safety, as well as async programming safety, as well as (partial) logic error safety (e.g., forgetting to release a lock for resource access) and so on. Anyone who's ever worked on a large codebase will agree without a second thought that finding a bug takes (at least) ten times more effort than writing code, wrestling even the strictest of compilers, so the case for Rust, effectively, is the philosophy of shifting as much responsibility on the compiler as possible and thus reducing the potential bug surface as much as possible. A human being is not capable of consistently avoiding all bugs that human beings realize can be made. A compiler, on the other hand, is capable of always eliminating all bugs that compilers realize can be made. The knowledge of such potential bugs is transferred from a community of experienced programmers to a compiler through an advanced type system for a programming language and a specialized structure of interfaces for a standard library.

The overall argument is very weak. Say, unknowns are everywhere, so the very existence of unknown hardly can be a reason to turn around.

> hyper-rational

You don't exactly call internet fandoms "rational" in any perspective. They're simply irresponsible for what they're saying. They simply don't care about your situation.

To add an anecdotal note, Rust sucks in its own ways. No single idea is good enough to be enforced in every single context. For example, Rust makes it harder to write simple mundane logic, which languages like Python and JS could express concisely. You're still stuck with verbosity like chaining dances and long type signatures, even when they hardly matter. A full-blown bureaucracy you must overcome every single day. This puts Rust in the realm of Java, which used to enforce pure OOP.

"Very hyperbolic" is itself on the hyperbolic side.

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

As-per my edit, simply by virtue of using glibc your program is no longer safe. Glibc has had vulnerabilities, and continues to do so (as unknown unknowns - just like all C software). If you're not using any stdlib then maybe.