Common Rust Lifetime Misconceptions

A memory leak can be unsafe though.

I read the comments you linked and don't really think they literally believe Rust is magic. I dunno though I guess I could imagine a vibe coder tacitly believing that. Not saying you're wrong. I just think most people say that tongue in cheek. This saying has been around forever in the Haskell community for decades. Feels like a long running joke at this point

I don't know the authors of those posts, so I don't want to put word in their mouth, but neither seem to be delusional about the "if it compiles, it works" phrase. The first one qualifies it with "most of the time", and the second one explicitly mentions using type state as a tool to aid correctness...

But I don't doubt there are people who take that phrase too literally, though.

When I’ve said that, I’ve meant that almost the only remaining bugs were bad logic on my part. It’s free from the usual dumb mistakes I would make in other languages.

> "Woah, Rust helps so much that I can basically think 'if this compiles, everything will work', and most of the times it does!"

I think is is a fairly bad example to pick, because the fact that the person says “I can basically think” and “most of the time it does” (emphasis mine) shows that they don't actually believes it will makes bug-free programs.

They are just saying that “most of the time” the compiler is very very helpful (I agree with them on that).

Both examples you linked are people talking casually about the nature of Rust, rather than about the specific rule. That goes very much with your parent commenter's assertion that nobody takes it literally. The first example even starts with 'Most of the time' (this is true, though not guaranteed. I will explain further down). Human languages are imperfect and exaggerations and superlatives are common in casual communication.

But I have not seen any resource or anyone making technical points ever assert that the Rust compiler can verify program logic. That doesn't even make sense - the compiler isn't an AI that knows your intentions. Everybody is always clear that it only verifies memory safety.

Now regarding the 'most of the time' part. The part below is based purely on my experience and your mileage may vary. It's certainly possible to compile Rust programs with logical/semantic errors. I have made plenty. But the nature of C/C++ or similar manually memory-managed languages is such that you can make memory safety bugs quiet easily and miss them entirely. They also stay hidden longer.

And while logical errors are also possible, most people write and test code in chunks of sizes small enough where they feel confident enough to understand and analyze it entirely within their mind. Thus they tend to get caught and eliminated earlier than the memory safety bugs.

Now since Rust handles the memory safety bugs for you and you're reasonably good at dealing with logical bugs, the final integrated code tends to be bug-free, surprisingly more often than in other languages - but not every time.

There is another effect that makes Rust programs relatively more bug-free. This time, It's about the design of the code. Regular safe Rust, without any runtime features (like Rc, Arc, RefCell, Mutex, etc) is extremely restrictive in what designs it accepts. It accepts data structures that have a clear tree hierarchy, and thus a single-owner pattern. But once you get into stuff like cyclic references, mutual references, self references, etc, Rust will simply reject your code even if it can be proven to be correct at compile time. You have three options in that case: Use runtime safety checks (Rc, RefCell, Mutex, etc. This is slightly slower) OR use unsafe block and verify it manually, OR use a library that does the previous one for you.

Most of the code we write can be expressed in the restricted form that safe Rust allows without runtime checks. So whenever I face such issues, my immediate effort is to refactor the code in such way. I reach for the other three methods only if this is not possible - and that's actually rare. The big advantage of this method is that such designs are relatively free of the vast number of logical bugs you can make with a non-tree/cyclic ownership hierarchy. (Runtime checks convert memory safety bugs into logical bugs. If you make a mistake there, the program will panic at runtime.) Therefore, the refactored design ends up very elegant and bug-free much more often than in other languages.

Comparing type systems is difficult, but the general experience is that it is significantly easier to encode logic invariants in Rust than in C++.

Some of the things you can do, often with a wild amount of boilerplate (tagged unions, niches, etc.), and some of the things are fundamentally impossible (movable non-null owning references).

C++ templates are more powerful than Rust generics, but the available tools in Rust are more sophisticated.

Rust certainly doesn't make it impossible to write bad code. What it does do is nudge you towards writing good code to a noticeably appreciable degree, which is laudable compared to the state of the industry at large.

They certainly know that you dont want to process garbage data from freed memory.

Soundness does not cover semantic correctness. Maybe you want to wipe $HOME.

The better phrase is that "if it compiles, then many possible Heisenbugs vanish"

https://qouteall.fun/qouteall-blog/2025/How%20to%20Avoid%20F...

"If it compiles, then only logical bugs will make it eat your homework"

Would output along the following lines be an improvement?

   error[E0597]: `buffer` does not live long enough
   --> src/main.rs:63:21
      |
   59 |     let report = {
      |         ------ borrow later stored here
   60 |         let mut buffer = Vec::new();
      |             ---------- binding `buffer` declared here
   61 |         let ctx = Context {
   62 |             config: &config,
      |             ------ this field and `buffer` are required by `Context` to have the same lifetime
   63 |             buffer: &mut buffer,
      |                     ^^^^^^^^^^^ borrowed value does not live long enough
   ...
   68 |     };
      |     - `buffer` dropped here while still borrowed
   help: consider making different fields in `Context` have independent lifetimes
     |
   4 | struct Context<'a> {
     |                ^^
   5 |     config: &'a Config,
     |              ^^
   6 |     buffer: &'a mut Vec<u8>,
     |              ^^
   7 | }