Remix.run Logo
▲ simonask 2 hours ago

Just because emotions seem to be always boiling whenever Rust is mentioned, I want to clarify for people who only follow casually that there is nothing unusual or scandalous about these finds.

The Rust project as a whole currently has 178 open issues with the tag I-unsound[1]. Many of these describe issues that only exist in the nightly compiler, of course, but it does happen that bugs are not caught before shipping. That's software.

[1]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+state%...

▲cowlevel 43 minutes ago | parent | next [-]

That there's nothing unusual about these finds, the Drop static lifetime bug, or cve-rs is proof that Rust is not, and probably never will be, memory-safe. It's still an improvement though.

▲hmry 13 minutes ago | parent [-]

Is a language only memory-safe if its implementations are completely bug-free? I guess no language can ever be memory-safe then, might as well throw out the concept.

▲cowlevel 8 minutes ago | parent [-]

Last I heard, Rust has no independent spec so the compiler is the spec.

▲dxdm 2 minutes ago | parent [-]

So? I don't understand how that matters here.

▲Sytten an hour ago | parent | prev | next [-]

Even more, the fact that unsafe blocks are a thing allows for this kind of deep scrutiny of the STD.

▲shevy-java 32 minutes ago | parent | prev | next [-]

> there is nothing unusual or scandalous about these finds

I would not go so far. I just mentioned in a separate comment, a minute before writing this here, that it is rather outrageous that the premier language for AI these days (aka Rust), has not used AI to find these bugs before. Would you not also consider that it should follow from simple logic that a language that is the premier AI language now, also would use AI as it preaches for it, to find bugs?

▲arijun 15 minutes ago | parent | next [-]

I’m having a hard time understanding you here. Are you saying that since rust is a good language for AI to write code in, it says something about the (lack of) power of AI, that it wasn’t what found the bug? Because the logic there seems twisted: “F1 drivers, the biggest users of F1 cars, almost never make improvements to F1 engines”.

▲WOTERMEON 23 minutes ago | parent | prev [-]

Are you paddling some? I’ve never seen rust described as premier language for AI

▲fsckboy 2 hours ago | parent | prev [-]

>that there is nothing unusual or scandalous about these finds

that there is nothing unusual is the scandal

▲simonask 2 hours ago | parent [-]

Why would you think that? Bugs exist in complex software no matter how hard you try, including software written in Rust such as the Rust compiler and standard library. Did you expect the highly competent people working on these projects to just one-shot everything?

▲cowlevel 42 minutes ago | parent | next [-]

Actually, software that probably has no bugs does exist, starting with the seL4 microkernel. Such software is usually pretty simplistic because that goes a long way towards proving an absence of bugs.

More practically, however, Rust has proven to have more memory safety bugs than GC languages. If you want memory safety you should go GC. If you want consistent performance or tight control over memory, and pretty good memory safety, then you should go Rust.

▲saagarjha a minute ago | parent [-]

Neither of these is true lmao

▲thesz an hour ago | parent | prev | next [-]

From the article: "The findings reveal three recurring patterns of misplaced trust in unsafe code: trusting code not to panic, trusting user-provided implementations to be correct, and trusting the underlying system."

The call to "panic" is an effect and can be checked at compile time. Haskell does this with MonadError class, marking up code that may throw.

Rust has Turing complete type system for years and still does not have effects of any kind.

To be fair, "trusting user provided implementation" is also has something to do with effects. Proper type system would require user-provided implementation to use only certain effects and nothing else.

So two of of found shortcomings are directly related to the type system and, specifically, to the choice of original Rust implementors to not to distinguish between pure and effectful computations.

Do Rust implementors highly competent? Yes, of course! They work on Turing complete type system. Will they eliminate two of three recurring patterns? I strongly doubts so. It is a design decision and these are especially hard to change. Changing it will also break all Rust source code produced to that point of time.

Is it a scandalous situation? For me, it is. The situation is so dire, actually, that "highly competent people working" has to be defended with trivially true fact that "bugs exist in complex software no matter how hard you try," instead of addressing core problem.

▲simonask 3 minutes ago | parent [-]

You're pointing out that there can exist a language other that Rust that is even safer, and prevents even more classes of bugs. That's trivially true, of course, but this language doesn't currently exist.

▲teiferer an hour ago | parent | prev [-]

You may have noticed the wave of "rewritten in rust" software in recent years, whose only (?) selling point was that this makes the software somehow automatically safe and if not bug free then at least significantly lower on bugs.

This finding is just yet another nail in the coffin of that myth.

▲irealis an hour ago | parent | next [-]

I have never understood this argument. Rust, by default, is safer. This is trivially true. But it also is not perfect.

This entire argument against Rust hinges on it somehow invalidating all of the improvements it does have, all the safety it does guarantee, just because it also has a few bugs. It's neither a myth that Rust is safer, nor is it a nail in the coffin for it.

Otherwise you must make the argument that just because unsafe exists, and is used, it is automatically as bad as let's say C - a language that has proven time and time again how trivial it is to make mistakes with. Something that just doesn't happen in Rust.

▲nopurpose 32 minutes ago | parent | next [-]

In addition to that, many of reported soundness issues rely on adversarial implementations for stdlib' traits by user's types, like Borrow::borrow or as_ref returning different value between back to back calls. You would do that if you try to break compiler, but not when writing regular programs.

▲Galanwe an hour ago | parent | prev | next [-]

The annoyance comes from the fact that your kind of _reasonable_ discourse on safety is always thrown when there is a bug, but never when there is a claim that rust is 100% by construction. I.e. It's always a defensive argument, but I never see someone step up to mention it on overly optimistic claims.

▲simonask an hour ago | parent [-]

I can't be defending the statements of whoever says this, but I do think that the reasonable way to understand it is that the fundamental model that the Rust compiler and standard library attempt to implement is safe and correct by construction, rather than as a statement about the concrete implementation.

Among software developers, we shouldn't need to provide a "assuming there are no bugs" caveat with every statement about how something works, because we know that bugs are essentially unavoidable at scale. We can say that Rust makes it much easier to avoid bugs, but nobody serious has ever claimed that they are 100% eliminated.

It's not like C or C++ compilers are bug free either, despite implementing much weaker models.

▲csande17 19 minutes ago | parent [-]

> the fundamental model that the Rust compiler and standard library attempt to implement is safe and correct by construction

This comes up a lot as a defensive argument too, but it's also pretty frustrating, because Rust's "fundamental model" is not a thing that really exists. There are project proposals to create one (such as https://goals.rust-lang.org/2026/roadmap-project-zero.html#), but at the moment it's just a vague set of vibes people gesture towards to dismiss all the problems with Rust-as-actually-implemented.

▲pseudony an hour ago | parent | prev [-]

Funny. I would think a GCed language was safer - maybe Haskell being the safest of all (outside even more niche languages) for its ability to encode so much in the type system.

Yet, for some curious reason, a substantial group of snake oil salesmen insist that only this one particularly cut puzzle piece (rust) fits the bill.

▲simonask an hour ago | parent | next [-]

Who, exactly?

It has been known for decades that GC was one way to achieve memory safety. That was one of the main selling point of Java back in the 90s - no more segfaults.

Rust was an absolute breakthrough, because it provides a second way to gain memory safety, this time without the significant drawbacks of a garbage collector, bringing memory safety to systems programming. That's materially different.

The only other previous attempt at this was Ada, which for a variety of reasons never quite fit the bill despite its obvious strengths.

▲dcminter 30 minutes ago | parent [-]

> Who, exactly?

I'm on your side of this, but there are Rust zealots out there and they're incredibly annoying.

(Edit to add:)

As a longtime Java guy (after a decade or so as a C++ guy) what drew me to Rust wasn't actually memory safety; that was table-stakes for me and Go might have lured me in if that was all I wanted. The low-cost (cognitive complexity is a cost) of memory safety was a factor, but it was the expressive type system that sealed the deal.

▲JuniperMesos 44 minutes ago | parent | prev [-]

Also you gotta write the garbage collector itself in some language that isn't itself garbage collected - usually C or C++, before Rust existed.

Anyway, it's basically slander to say that people advocating Rust are snake oil salesman. Rust is a genuine improvement to systems languages over the existing options (primarily C/C++) in multiple respects, not just memory safety; it is not a panacea that solves every problem or eliminates every possible bug, and no one involved with the project ever claimed that it did.

▲dcminter 32 minutes ago | parent | prev | next [-]

Yes, that's a myth.

I, like many others, still think that a language that requires a bug in the compiler for a certain category of error to be exhibited is preferable to one that has no such guarantees. I like C but it's not crazy to consider rewriting a tool in Rust for memory safety reasons.

▲no-name-here 41 minutes ago | parent | prev | next [-]

> automatically safe

> bug free

In most discussions involving Rust I hear those “counter” criticisms, but is it a common claim by Rust proponents that Rust makes software bug free, etc? I feel like I don’t really encounter the original claim that others are arguing against.

▲Certhas an hour ago | parent | prev [-]

Because?