Why the case for Rust is not particularly compelling

Extremely weird and ahistorical. I wouldn't go so far as to say that everyone should use rust, but this argument is against a straw-man. Roughly speaking, it skips over the fact that

1. history has demonstrated that memory bugs are easy to produce and hard to find and 2. even a single memory error can be devastating in terms of data and money and productivity lost

If Rust eliminated most or a large class of memory errors and it was just as productive as C/C++ it would be a no brainer to at least write new, independent, systems in Rust. I think its reasonable to assume that Rust manages to eliminate many memory errors, but whether it comes at too high a cost is the real question, along with the lock in and network effects that our legacy systems have.

This essay basically doesn't address anything real.

>In programmer world, you really can’t beat this argument. Because programmers are hyper-rational.

This may be one of the biggest lies I've ever seen on the internet

Author is likely unsophisticated and frustrated that their competency in c/c++ fail to translated to rust without a bunch of additional effort.

The article contains several strawmen that aren't constructed particularly well even by strawmen standards. They're not even really knocked down. Just gently pushed where they lean against a nearby wall.

But if you go to the very end, then I think we can infer what's going on here:

> ... the growing movement toward legislation. [...] Because we could end up in a less secure future, where nobody understands why, with red tape that prevents you from finding out what went wrong.

Rust contains many low level details that you have to understand. And type inference, generics, associated types, two macro systems, algebraic data types (which have to concern themselves with low level details), pattern matching, and ownership and borrowing. It is hard to get up to speed with all of these concepts.

Compare that with python. With python you have to understand dictionaries and the call stack. That's about it (imagine me handwaving a bit).

Additional concepts that you have to understand in order to be productive (or get the job done at all) is a consideration that is worth making. However, having a hard time groking the affine types and the borrow checker isn't really an argument against Rust.

This is a fundamental misunderstanding of what's great about Rust.

The case for rust is not its memory safety, but its expressiveness through zero cost abstractions, one of which is memory safety.

Eh. Much current C code is somewhat safe-ish because of Herculean efforts to not screw it up.

If the author can use “C” to mean “C or C++” (WTF) then I’m going to use “Rust” to mean “any language designed to make it easier to write correct code”. Rust’s memory handling removes so many footguns like use-after-free that whole classes of exploits evaporate. Then it adds a type system that makes it hard to write whole classes of logic errors. For the encore: since a programmer knows that code that compiles cleanly doesn’t make those related mistakes, they can spend more of their time concentrating on algorithms and business logic instead of RAM bookkeeping and trying to remember whether the “x uint64_t” argument is supposed to be the file offset or the size of the data or the number of chickens to pack because they all use the same type.

I can write assembler. It’s fun. I’d hate to do more than a smattering of it for a living, because life’s too short to keep manually doing what a computer’s good at. Rust lets me think about what I’m doing instead of how I’m doing it, so instead of worrying about the trees I can make sure I’m taking care of the forest.

1. Find one feature of a language and argue that it's really not _that_ great because it introduces costs.

2. Never mention these costs and declare the whole language is "not particularly compelling".

Just as my own aside, before Rust, the "cost" of memory safety was either a garbage collector or infallible programmers.

The author is mistaken about the perceived lack of research into alternatives.

We know how to write secure C/C++ code. The methods are very expensive and don't scale to large engineering teams.

Government agencies as well as large companies - including Microsoft and Google - have researched this very subject for decades. The problem is that even very small probabilities become a significant issue at scale.

I'm not sure there's much to take away from this article. The author spends most of his words arguing against himself and then ends with a very confusing paragraph with a vague call to "understand what security means", a reference to "the growing movement toward legislation" (what legislation?), and the implication that we might be less secure, somehow. Maybe there is some subtext I'm supposed to know before reading, but on it's own, overall just incoherent.

> But… hang on. What about all the code that doesn’t have vunerabilities?

> …we have tonnes of safe code, and no one knows why its [sic] safe.

This is not a serious person.

I guess there could be more vocal zealots in the Rust Evangelism Strikeforce, but as a member myself I strongly disagree with the premise of the article. Rust is currently the only mainstream option for memory safe development with a focus on performant systems development. The latter emphasis being the primary motivator of people using C/++ in the first place.

If you aren't particularly concerned about systems development or rubber-to-the-bare-metal performance then there are tons of options: managed languages. C#, Java, Go, etc.

If the article is advocating for C/++, please, stop. The claim that there are some safe programs in the world of C is categorically false. [Edit] for example, as soon as you use glibc: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=glibc

Given that an estimated 70% of security vulnerabilities are currently memory safety errors, I think that justifies the use of Rust all by itself.

But a far greater gain is that Rust is designed right from the start with tighter semantics which make it more suitable static analysis, and that it is, unlike C/C++, largely free of undefined behaviour.

Said with love, as someone who recently picked C++ up again largely for sentimental reasons, but every one of these apologias sounds like this:

https://www.youtube.com/watch?v=O8YfgxF3APY

This is not a particularly compelling post.

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.

Unless a system can be proven safe (within whatever the limitations of that proof are) , it is by definition not proven safe. If it can - and most importantly, is - tested for security issues (which are not the same as functionality, though there may be overlap), then some amount of confidence in its safety can be assessed, but it cannot properly be said to be declared as safe simply because of age. Hand waving and saying that uncompromised, at least as is known, code is known safe is simply wrong. Such code is simply not known as unsafe. Conflating the two as equivalent is not good engineering, but it is all too frequently a business case of unknown risk acceptance.

This seems to be an argument against why everything must switch to Rust. It's almost a complete straw man because most Rust developers aren't even making the claims he's arguing against, but there is a little bit of truth.

There is such a thing as Rust fanaticism, people with a near-religious belief that Rust will solve all of coding's problems. You can identify them because they view use of unsafe as a great sin.

It seems he's arguing against the Rust fanatics, and not Rust programmers in general or the language itself.

Just that in those unknown unknowns lurk many more memory safety issues, that we have not yet discovered and the longer we continue to run that code, the more likely we will some day get hurt by them. Also we don't know anything about safe code, until we have proven it to be safe, either mathematically (difficult!) or by proving a type system sound and using that for implementing things.

So I'm not sure entirely followed that. I think there's a significant thread of frustration with portions of the community that push rust as the end all be all that has to be used everywhere (or at least it really does feel like that sometimes), and I'm sympathetic to that (I tend to be in the camp of "if you can use a language with managed memory than just do that"). But I really don't understand the thing about unknown unknowns. And maybe the part before that? I mean, it would be interesting to talk to the OpenBSD developers and see why they don't have a track record of shipping memory vulnerabilities, if that's the intention.

> This is analagous to World War 2 bomber design (bear with me).

What follows that sentence has to be a contender to win the prize for the most tortured analogy in a programming language discussion. You see, safe languages are bad because they slow you down, and if you're slow, the Nazi anti-air guns (that is, security vulnerabilities) can catch you. You need to code faster to dodge those bullets! Write in C to stop the Nazis!

Earlier in the article, there's a lot of hand-waving that there's a lot of secure software out there that's written in unsafe languages, so memory safety isn't needed. No proof of this. If you make a claim like this, at least be specific and enumerate examples of software for which that's the case. Then we can verify this claim against published vulnerability lists from the past few years. Spoiler: every significant C program has had memory vulnerabilities.

But maybe those aren't important compared to other security issues, which is another a common claim and one that's hinted at here? Maybe C allows you to code fast enough to dodge other kinds of Nazi bullets/vulnerabilities, and that's worth it? Well, people do enumerate stuff like that, and despite most programming nowadays happening on the web, a memory safety issue is still at the top of this list, for example: https://cwe.mitre.org/top25/archive/2023/2023_top25_list.htm...

Perhaps those metaphorical airplanes were still to slow, and the programs that were counted in this should actually have been coded in assembly to be even more secure, what do I know.

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.

"[If we all wear seat belts] we could end up in a less secure future, where nobody understands why, with red tape that prevents you from finding out what went wrong."

Insane.

This article is not very compelling. My main reservations with Rust are (1) the community (2) licensing culture. The community seems to have a drastically different culture compared to the earlier hacker culture, being weirdly obsessed with social justice and anti-libertarian. But this will probably be diluted the more people use it, so it is not a huge problem. The bigger issue is the tendency to use permissive licenses like Apache or MIT instead of GPL. By writing more and more new code under MIT/Apache it undermines the protections we get from GPL'd code. This boils down to a kind of friendliness to corporations and/or authority in general, which, imo, is dangerous to free software. I was also told that the justification for the permissive license is "I would like to get hired by a $BIG_TECH, and letting them use my package without requiring source release helps with that.".

This case against Rust is not particularly compelling:

1. It strawmans the pro-Rust case by suggesting that Rust is presented as a panacea.

2. It argues that because Rust can’t help with everything, it helping with an important issue (memory safety) is irrelevant.

The crux of it is basically this:

> But this is just throwing the baby out with the bath water. Clearly. Because we have tonnes of safe code, and no one knows why its safe.

We do know that it is safe. We know that it is memory safe. This rhetorical conflation of memory safety and some other form of safety is an issue.

> We need diversity in strategy. We need to actually understand what security means and how existing programs that ARE secure, are written that way.

Absolutely. And using tools that help eliminate entire classes of bugs is an important part of that diversity of strategy.

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.

> “What the fuck are we doing in the cases where there are no vunerabilities?”.

Keep using that software? I mean, as an example, I don't really think anyone is rushing to re-implement sel4 in Rust because of security, or to re-implement sqlite, which has an obscene level of testing that is likely ~on-par with Rust's own memory safety guarantees.

So the answer is "don't do anything".

Of course, deciding that something is safe is really hard. I used two examples where the work is or borders on formal verification.

> How you write code, how you design code, what environment you are in, what your domain is, what the complexity of your problem is. None of that matters.

This just isn't true, and it's kind of a confusing argument. First off, Rust is designed with C-interop in mind exactly so that you can partially replace some components in pieces. That's how Firefox has adopted Rust - in places where you can't afford to thinking "well maybe it's secure already".

> How much program wisdom, when it comes to how to design a memory safe program, is being chucked out the window to pursue a “security by language design” approach?

Basically none, speaking as someone who has some security knowledge.

> Having a “secure by design” language SPECIFICALLY to the detriment of everything else is not going to solve your security problems.

Total straw man here, in no way is Rust to the detriment of other security processes, in no way does it obscure our ability to leverage other techniques. Ironically, it's quite the opposite - Rust has been able to leverage dynamic analysis like clang sanitizers for ages, it's pushed fuzzing from "a thing security people do sometimes" to "a library that devs actually use", and even has tools for formal analysis of code (miri). Rust has been eager to adopt new mitigation techniques like safestack or CFG. Rust is far more than language safety.

Skipping over the analogy bit because analogies are a waste of time.

> We need diversity in strategy.

We have it. Rust already does this.

> We need to actually understand what security means and how existing programs that ARE secure, are written that way.

No one disagrees with this.

> Because we could end up in a less secure future, where nobody understands why, with red tape that prevents you from finding out why.

Totally unsupported claim here tbh.

Anyway, I found this all very uncompelling and it sounds like someone who isn't super familiar with computer security opining on the matter.

Beyond that, the value proposition is far more than "Safer than C/C++".

How Rust made it into the kernel is beyond me. Torvalds should have waited 3 more years and then he should have chosen Zig.