upvote
How is this different from any other compiler bug?

There was one in the Linux kernel a while ago that mistakenly eliminated an important null check.

Is this different?

reply
No, people who don't actually use Rust just like to pretend it's something more than it is, for some performative outrage or something.

Here's the current list of similar (unsoundness-causing) open compiler bugs in Rust:

https://github.com/rust-lang/rust/issues?q=state%3Aopen%20la...

reply
In theory it would be possible to formally verify the soundness of the borrow checker. Maybe with AI advances we'll be able to do that in the near future. I mean, how much more complicated can it really be than proving Navier-Stokes?
reply
Note that the Lean kernel itself is not formally verified.
reply
You can't formally verify the soundness of something that inherently necessarily relies on hardware implementations that themselves could be faulty.
reply
You take hardware properties as axioms (for instance, ARMv6 cache coherency is specified in detail as part of the lengthy spec, even though you have no guarantees that the hardware actually is faithful to the spec)
reply
You can certainly verify the soundness of what is within your control, the compiler code, which is what is being suggested above.
reply
You can formally verify that the algorithm has the desired properties, though. If the hardware requires additional properties for soundness, then that would only be an error in the properties, not in the proof. (Of course, that would no longer prove soundness on that hardware.)
reply
... and even if you formalize it, it could still be false due to an error in the theorem prover itself.
reply
And even if the theorem prover has no errors, the math behind the theorem prover could be inconsistent according to Gödel's incompleteness theorem. So even in principle, we can never be completely certain about the soundness of Rust, though the more theoretical concerns tend to be dwarfed by basic human error.

I think it's a good thing to keep in mind, that the actual implementation of Rust almost certainly isn't sound. Even an "ideal Rust" still has unsafe, which can affect the soundness of even faraway safe code. But I don't think it's nessesarily wrong to talk about Rust as if it were safe. Much of our communication has implicit assumptions, and the way we talk about Rust is no different. It would be exhausting to qualify every discussion of saftey with "assuming the compiler has no bugs", "assuming all unsafe code follows the (not fully specified!) rules", etc.

Ultimately it's like any other implementation of theory into practice. The theoretical model of Rust lets us reason about and design an implementation to achieve certain practical goals even though the model is a simplification of reality. In Rust's case, practical use has demonstrated it achieves design goals like reducing bugs and reducing development time (compared to peers like C++) to a substantial degree.

reply
It’s like Python describing itself as fast. Everyone knows that means “fast enough for intended use”, not “fast in an absolute sense”. But for some reason when Rust describes itself as safe people take that to mean in an absolute sense.
reply
Rust scores a lot higher on the safe scale than Python scores on the fast scale. Also, who are these mythical people that call Python fast?
reply
Python calls itself fast in its own webpage, pretty predominantly:

https://www.python.org/about/

  Python is powerful... and fast; plays well with others; runs everywhere; is friendly & easy to learn; is Open.
reply
Or more likely, an error in the formalization. "What you proved is true, but it's not sufficient for what you care about." See for example WPA2 KRACK attacks after WPA2 was proven secure.
reply