This is not the first soundness bug. Some bugs aren't fixed for years. The Rust community is well aware that such bugs exist, will be found, and address them just like other high impact bugs. In other words, if you paid the slightest attention to the development of Rust language, you would know this is surprising but not unexpected, and has happened many times.

People in sugar glass houses shouldn't throw stones :P

You got my upvote and this one decade old issue:

https://github.com/rust-lang/rust/issues/25860

[flagged]

You got my upvote.

It looks like 18 of the 30 issues listed in table 4 had already been fixed when that paper was released, and there is activity in most of the rest. One was recently flagged as being fixed by -Znext-solver, and another has the submitter write that it is fixed, but the issue is not closed. And that's before you consider the impact of the individual issues; how many of the remaining issues impact "real" code?

So I don't think it's fair to claim that "no-one cared".

I don't think "no one cared" is a fair characterisation. The paper doesn't support this conclusion, and from experience I'd say that the two difficulties in fixing unsoundness are doing so without breaking existing code (Rust guarantees stability unless the code is unsound, and introducing previously missing checks can cause sound code to stop compiling, which is a problem if it occurs often) and doing so in a reliable way that can be supported long-term. Rust is currently in the progress of stabilizing next-solver and Polonius, both of which fix multiple long-standing bugs and have been worked on for years now due to intrinsic complexity, performance considerations, compatibility issues, etc. It's not that no one cares, it's just that this stuff is hard and takes time.

The borrow checker has been rewritten to improve this once, and another attempt (that is thought to clear up the rest) is on the way.

Things taking time to fix is not the same as not caring.

lol do you think that cve-rs was required? there is literally an l-unsound tag on rustc's github, this isn't some embarrassing or secret thing.

Safe rust is safe, granting `unsafe` and compiler errors. This isn't a secret.

in compare to c and cpp? it is

Let us not conflate a bug in an implementation (rustc) with a defect in the language (Rust).

Hey, but it's genuinely a nice language. Maybe they're not the most brilliant of type theorists, but even without ownership/borrowing, just stuff like traits, structs/enums/unions with pattern matching, etc, is done quite well.

What's wrong with Wales?

The tech of the rust language is real though and is providing real world value

It seems the bug here was caught by Asan instead of at compile time, so basically, for this one bug, rust is reduced to C++-like behavior. You’re still better off using rust because of all the bugs the borrow checker does catch.

The practical upshot to me is that you should be running your rust tests under asan.

It's possible to scan compiled programs at the assembly or machine code level. Not enough people do, which is fair enough because it's a slog, but it makes all compiler UB transparent to the analysis.

That is less and less true by the day, for better or worse.

That was a bit generic and easy to swap "Rust" for whatever...

  Dense syntax pulsing
  Writhing and undulating
  What designer, who?