> The "Rust is safe" is not some kind of absolute guarantee of code safety

Exactly. Some people act like we don't have the whole branch of "formal proofs" in CS. Memory safety is just once aspect of program safety.

Like, IMO, programs written in Coq, F* or even C programs verified by Frama-C are much more "safe" than Rust programs that advertise their "safety" on the mere fact that they are written in Rust.

FWIW, Walter Bright have been, for years, proposing the C standard to fix the billion dollar mistake in a backwards compatible way. Stroustrup is the head of the C standards committee, just saying.

Typo? Stroustrup is not even a member of the C standards committee.

Stroustrup voice counts one vote like everyone else on ISO C++, doesn't matter what role he played on the language creation.

Also the current head of the standards comittee is Herb Sutter.

Can you elaborate on that, couldn't find the proposal, I want to learn more about it.

The reality is that people are adding critical code to the kernel and surrounding infrastructure (OpenSSL) on a Friday night after a long weeks work and never bother to look at it again.

We absolutely need something like Rust to cover our backs!

The idea that Rust can solve this problem is ridiculous to me. The types of bugs that sleep-deprived contributors writing fire-and-forget code will make will just shift to something that the borrow checker doesn't help with.

It's not ridiculous, it's a proven fact! Rust obviously won't stop logical errors, but it will put an end to the almost unending cue of memory and thread related bugs.

Mind you that Firefox, for example, has been around for 17 years. Every month I get security updates fixing multiple memory holes in the code each of which could potentially allow anyone to take over my machine. Seventeen years!! They must have fixed hundreds if not thousands of such bugs by now, and every month more are repaired by updates.

We'd have none of those had it been written in Rust.

Also mind the time saved by developers not having to hunt for such (hard to track down) bugs!

> We'd have none of those had it been written in Rust.

Except for memory issues in JIT-generated code from Javascript? Not all browser vulnerabilities are caused by memory safety issues in the code generated by the Javascript JIT, but several of them are (particularly "type confusion" vulnerabilities). Rust might help avoid vulnerabilities in the code generator, but not in the generated code.

So, no bug that the borrow checker can help with? Sounds like a big win to me, why is it ridiculous?

The parent comment implied that this meant that there would be fewer bugs. That is definitely not what happens.

The factor that actually generates the bugs is the tired person writing code they will never read again or use. The borrow checker won't help with that.

I write code with different types of bugs in C, Go, Rust, Javascript, and Verilog, for example. I rarely write code with no bugs, especially when I have no real connection to the code.

GP comment implied there would be fewer exploitable bugs. That is definitely what happens.

If you think there's the same amount of severe exploit from software written in Go/Java/Javascript and software written in C/C++, you are just factually wrong.

70% of exploitable bugs from large company products (M$, Apple, Google) ARE memory safety bugs.

I do not agree with you, and I think it's a pretty strong claim to make that Rust code has fewer exploitable bugs than other code without evidence. The fact that 70% of "exploitable bugs from large company products" are memory safety bugs does not imply that those products will be any harder to exploit when re-written in Rust, just that they won't have certain types of memory safety bugs - which happen to be 70% of the known exploitable bugs that have emerged.

One big reason why we have so many CVEs for memory safety bugs is that they are very easy to find with analyzers and easy to programmatically test. We currently live in a world where a lot of deployed code has not had the benefit of those analyses, but the attackers do. Hence the huge number of CVEs. Rust closes that asymmetry, which is significant.

It does not mean that we won't move on to a new class of exploitable bugs that show up due to a new class of analyzers.

Also, exploitation means a lot of things to a lot of people. The fact that it's really easy to crash a Rust program could also be considered an exploit (as a number of CVEs do).

Just using Rust does not save you from exploits. Using Rust well makes it easier to be safer.

So let me get this straight, you're saying that:

1. You acknowledge others' reports that 70% of exploitable bugs are rooted in memory safety problems.

2. You acknowledge that Rust helps reduce the number of memory safety bugs.

3. You resist any conclusion that Rust therefore reduces the number of exploitable bugs.

4. The stated reason for such resistance is "but but but they might exist and you might not know about them and something something something about how analyzers have gotten better."

1+2 alone seem like a pretty clear open & shut case to me. Your (4) looks like grasping at straw to me. You complain about "without evidence," but 1+2 looks like pretty compelling evidence to me.

One also has to wonder what kind of evidence would meet your standard. What evidence would convince you? And is that evidence even obtainable?

(1) is wrong. I said that 70% of reported exploitable bugs are rooted in memory safety problems. Not 70% of exploitable bugs. There is a big difference. In other words, I am suggesting that we have found a lot more of the exploitable memory safety bugs than other classes of bugs, which skews the number high, and that there are a tremendous number of latent exploitable bugs that are not related to memory safety that we haven't found out how to find yet (in a systematic way). I am also asserting that the Rust borrow checker likely won't help with those latent bugs.

The evidence that would convince me is ~10 years of a notable reduction in both total CVEs and total monetary value of exploits of that software (or a comparable piece of software). There is almost nothing that would convince me today that Rust is inherently more secure than C or C++ (particularly modern C++), except in the small class of applications that rely solely on memory safety for security and cannot use a garbage collector.

By the way, I do have an application running in production today that fits that requirement, and I wrote it in Rust.

Total CVEs is a poor metric given that we (Rust programmers) tend to file CVEs far more liberally than C or C++ programmers. More to the point, the evidence you claim to require is just that: reported exploitable bugs. Which seems to have the same problems as the evidence that has already been presented to you.

> I am also asserting that the Rust borrow checker likely won't help with those latent bugs.

Kind of a silly assertion, no? Particularly given you've failed to characterize these "latent bugs" other than the fact that they aren't related to memory safety. You've also failed to provide any compelling commentary regarding whether these "latent bugs" are present in C or C++ programs. If you believe they are, then Rust still makes the situation better by reducing the number of exploitable bugs by reducing the number of memory safety bugs.

Methinks you are suffering to an appeal to ridicule. Your comments are written as if someone is saying "Rust will eliminate exploitable bugs." Nobody has said that in this thread. More to the point, I'd be willing to wager that nobody with any modicum of credibility has ever said that.

Wait, so reporting bias in CVEs makes my proposed experiment bad, but your assertion about 70% of CVEs okay? Surely all the memory safety bugs that show up in the next 10 years will make this no contest...

Onto latent bugs: part of the idea of latent bugs is that they are latent, as in we don't know what they are yet. I am just pretty darn sure that we haven't found all the bugs in computer software, or even all the possible types of bugs. Spectre didn't show up until 2018, and it was a totally new type of bug.

I am pretty convinced, after working on huge-scale systems that get fuzzed really well by their clients, that we have found less than half of the exploitable bugs in Linux (and other similar systems). I'm not suggesting that Rust will hurt here, just that there's no evidence that it will. They will probably show up in C and C++ code too, but you never know.

By the way, one class of vulnerability that Rust code tends to introduce when compared to C++ code is supply chain attacks. Cargo/NPM/Pip are attack surfaces. So far, the worst version of this that I have heard about in Cargo was that several packages started printing some harmless politically-motivated text on startup.

Also, let's get this straight: I am saying that the claim "Rust reduces exploitable bugs" has not been proven yet. Let's stick to that, shall we?

> Also, let's get this straight: I am saying that the claim "Rust reduces exploitable bugs" has not been proven yet. Let's stick to that, shall we?

I don't know how one "proves" that claim. But it definitely has enough supporting evidence to be a very reasonable belief. I certainly believe it.

I just find your entire approach here to be so strange. On the one hand, you're demanding concrete evidence, but on the other, you're waving your hands about latent bugs and quantifying the number of known bugs with zero supporting evidence.

I think this is one of those things that's common sense and you're overthinking it.

I think it's a given that idiomatic Rust code has less memory bugs than run-of-the-mill C code but IMO, this debate boils down to this question:

"Do static analyzers like cppcheck, Frama-C, Coverity or NASA's ikos catch more bugs (including memory bugs) than idiomatic Rust code?"

We have to consider the added complexity of the Rust language and the massive man-hours required to re-write old C code-bases. It's a trade-off.

Yes there are many trade offs to consider and context matters. But that is not the conversation that pclmulqdq is having.

From experience, no. At least cppcheck, clang tidy, and coverity together still miss aome fairly simple use-after-free on the stack. Asan or valgrind can catch it, as long as you have a unit test that would cause it, which might require 100% code and branch coverage. In more complicated cases where it somehow dependsnon inputs, even that might not cut it.

Speaking about tools like Frama-C, it is important to note that while there is an overhead during development of Rust programs because of the type system, proving the absence of runtime errors in industrial size programs using Frama-C is not something easy, and it remains quite costly (and to be fair, far more costly than making Rust programs type). However, it is true that you can catch some errors that are not caught by the Rust type system, say for example, integer overflows. But I would not bet that all problems caugth thanks to the type system of Rust can be caught using Frama-C.

Now, if we focus on functional properties (proving that the code is correct), one terribly hard problem when dealing with real world programs is handling the shape of the memory. That can make some proofs awful and really hard to complete. In a language like Rust, you can get a lot of information about the shape of the memory and the memory separation for free thanks to the type system. That would make proofs really easier (this is for example what is done, but with far less precision than what the Rust type system could provide, in the different memory models configuration in Frama-C/WP and it can already dramatically improve proof performance).

It probably does not justify rewrite everything, nor changing verification tools chains that are in use in some critical domains. However, I would definitely love working on and working with a Frama-Rust tool ;)

The idea that people will just shift to other kinds is ludicrous. There isn't a fixed quota of bugs per developer-hour. In my personal experience, Rust code absolutely has fewer bugs than most other languages.

Several large surveys have found that approximately 70% of bugs in C and C++ projects are memory safety issues.

I will say that I have written a fair amount of Rust, and never had a bug in a sub-100-line Rust program, which is a huge difference compared to C.

For more complex things, arguing with the borrow checker has often led me to weird solutions that seem to work, but are unlikely to be 100% bug-free.

I would also like to point out that the surveys are looking at known bugs, and memory safety bugs are now very easy to find, thanks to the large number of memory safety analyzers that exist.

The analyzers exist because memory safety problems are significant, but the fact that they are 70% of known bugs does not imply that Rust code will have 30% of the bugs that you would find in a C equivalent. In my experience, if the C equivalent is short, Rust code usually has 0% of the bugs! If the C equivalent is long and complex, it could be a lot higher.

> led me to weird solutions that seem to work, but are unlikely to be 100% bug-free.

So you're telling me you don't unit-test your code? Big red flag there!

Rust is one of the few programming languages where unit testing is an integral part of the toolset.

I'm not sure how this relates to the post, can you elaborate?

Many of the Rust "evangelists" thinks/behaves like Rust's guarantees are absolute and leads to absolutely unbreakable software by default, and advocate that the language is the silver bullet combining abilities of C, C++ (depending on application) without any of its downsides.

When you hit a limitation you really need to implement in Rust, they say "Hey, there's unsafe{}, use that". Also, they advocate that unsafe{} is equal to C/C++ is programming freedom, which is again not.

When they're reminded that reality is not like that, they get upset and defensive. This comment is a nice flag to remind this reality.

I congratulate Rust for being what it is, but it's not a silver bullet and it's not the next C or C++. It's just a very nice programming language for various applications.

Being all shiny-eyed doesn't work in CS or programming in general, and also hardware doesn't work like that (a deterministic, perfectly good behaving, spec-obeying magic box with some included smoke for higher performance).

> Many of the Rust "evangelists" thinks/behaves like Rust's guarantees are absolute and leads to absolutely unbreakable software by default

Can you point to (high-profile) evangelists that actually push this view? I think the people you refer to are a loud minority of developers who possibly don't even write professionally in Rust. I've never read or heard this position from experts.

While the people I talk with are not high profile evangelists, all of them are using Rust in their professional life for work.

Maybe the messaging should be clear, and hype should be better controlled from top to bottom, because I never talked with anyone who doesn't casts stones to C & C++ and badmouths it while saying that Rust is the one, and only, and the last savior we need.

BTW, I'm not against Rust, but I don't use LLVM. I'm waiting gccrs to dive into the language.

I'm curious, why not use LLVM?

I'm a big GPL advocate, and publish I everything I can publish under GPLv3. Also, I want the code I publish to be able to be built with openly available tools. In other words, I want my software to be free and can be easily reproduced/built. This is the first aspect.

Second aspect is I don't like the behavior of LLVM ecosystem which is trying to subtly EEE gcc toolchain.

Lastly, I don't desire to be able to build a project I developed, or cloned to be only can be built with "clang/llvm/20201024+somecompanyClosedGitBuild20210514+bp1" which is available in binary form for a single distribution for a specific architecture. I have experienced SDKs and other software like that, and I don't want to go through again, or put anyone through that hoops.

> Second aspect is I don't like the behavior of LLVM ecosystem which is trying to subtly EEE gcc toolchain.

As opposed to GCC, which not-very-subtlety added extensions onto C which hurt portability?

GCC really shot themselves in the foot by making their architecture so difficult to use as a library, even from GPL code.

> I never talked with anyone who doesn't casts stones to C & C++ and badmouths it while saying that Rust is the one, and only, and the last savior we need.

So here is one, Ada was already that saviour in 1983, and in every use case where using a GC is an option, there are already plenty of options besides Rust.

Also until Rust compilers get fully botstraped, knowing C++ is a requirement to contribute to the compiler's backend.

Has Ada ever been the most loved language on the Stack Overflow developer survey for seven years in a row?

There are plenty of options besides Rust, but none that have & and &mut which eliminates many classes of bugs in both multithreaded and single-threaded code.

Stack Overflow did not exist during the first decade of Ada's existence, nor there was a free beer compiler for it.

Ada is cool, but as far as I understand it doesn't give you memory safety in the presence of dynamic allocations? Unless you use recent improvements to spark? It's hardly a superset of the safety features rust has.

It surely does, RAII exists since Ada 95.

https://www.adaic.org/resources/add_content/docs/95style/htm...

You are not supposed to call Ada.Unchecked_Deallocation() directly, rather from Ada's version of "Drop".

Then SPARK allows for formal proofs that one actually does the right thing, integrated into the language as of Ada 2012.

The cherry on top of the cake is that the language is also getting affine types on top of the already battle tested features in 40 years of production deployment into high integrity systems.

Who said anything about RAII? Having RAII doesn't make C++ memory safe. If you can take a reference or pointer to some RAII-created vector, and access it after the vector is gone… then you're not memory safe?

Yes, SPARK exists, and is very cool. I think there's work on a similar system for rust (or ferrocene, anyway, which is being co-developed by AdaCore: https://blog.adacore.com/adacore-and-ferrous-systems-joining...). It also seems that SPARK now has memory ownership and aliasing support, but only since ~2019 (https://blog.adacore.com/using-pointers-in-spark), and with clear inspiration from rust. It seems to me that this addition to SPARK was felt necessary by the AdaCore people, meaning that rust had something Ada did not support (or did not support well).

I mean I'd personally rate the opinion of people who actually use Rust higher than people who don't.

Rust isn't a silver bullet but it does shift the balance materially.

> because I never talked with anyone who doesn't casts stones to C & C++ and badmouths it while saying that Rust is the one, and only, and the last savior we need.

I do definitely cast stones on C/++, especially considering that a C project I've rewritten in Rust uncovered several memory safety issues from the very first run. Another C project I've approached also showed C-specific issues from the very beginning.

On the other hand, I don't define Rust and the savior and so on; to be specific, memory safety is a very serious issue, but not the only one, and memory safe languages solve a very serious issue, but not all the issues. Additionally, I think Rust is a niche language; other memory safe languages may be more productive for the majority of the use cases ("webcrap", like a famous software engineer described :)).

Now you know one!

>Many of the Rust "evangelists" thinks/behaves like Rust's guarantees are absolute and leads to absolutely unbreakable software by default, and advocate that the language is the silver bullet combining abilities of C, C++ (depending on application) without any of their downsides.

Where are these people? I'm not doubting that they exist, but I've never come across one and I've been in the rust community for several years now.

This is misunderstanding the point of unsafe.

All memory-safe languages in existence have safe abstractions built around unsafe code. For example, most JavaScript runtimes are written in C++. The point of unsafe Rust is to be able to use the same language to write both safe and unsafe code.

On the flip side, almost all C and C++ is unsafe code. The point of unsafe Rust is to be able to reserve brainpower for small subsets of code while having a relaxed posture towards most of it.

> When you hit a limitation you really need to implement in Rust, they say "Hey, there's unsafe{}, use that". Also, they advocate that unsafe{} is equal to C/C++ in programming freedom, which is again not.

I'm interested. How does rust unsafe give you less freedom than let's say c or cpp?

Rust's unsafe still needs to uphold the rules of safe Rust. It's not a license to just do whatever you want.

There are often ways to do whatever you want, but it's not as simple as "I have a raw pointer now let's goooooo."

I'd describe it as different, not "less", but I wasn't the one who said it originally.

One is a post about Rust in the Linux kernel, and the other is Linus talking about Rust in the Linux kernel on LKML.

What would you like elaboration on? The relationship seems pretty clear to me?

Those posts are actually more substantive and less negative than they might seem from these blurbs.

It’s not that Linus is against Rust at all, just clearing up some disagreements.

I see Linus has slightly tone down his ad hominem, but it's certainly still linus typing these words.