11 ms·

Common Rust Lifetime Misconceptions

• nromiun 10mo ago
  > It's possible for a Rust program to be technically compilable but still semantically wrong. This was my biggest problem when I used to write Rust. The article has a small example but when you start working on large codebases these problems pop up more frequently. Everyone says the Rust compiler will save you from bugs like this but as the article shows you can compile bugs into your codebase and when you finally get an unrelated error you have to debug all the bugs in your code. Even the ones that were working previously. > Rust does not know more about the semantics of your program than you do Also this. Some people absolutely refuse to believe it though.
  • littlestymaar 10mo ago
    I don't think anyone believes the “if it compile it works” phrase literally. It's just that once it compiles Rust code will work more often than most languages, but that doesn't mean Rust code will automatically be bug free and I don't think anyone believes that.
    • emilbratt 10mo ago
      Yeah, even the official Rust book points it out and if my memory serves me right (not punintended) also gives an example in the form of creating a memory leak (not to be confused with memory unsafe).
      • spookie 10mo ago
        A memory leak can be unsafe though.
        • 201984 10mo ago
          Then why is Box::leak not marked unsafe?
        • estebank 10mo ago
          "unsafe" or `unsafe`? One is the general meaning of the word, the latter is "it invokes undefined-behavior".
          • spookie 10mo ago
            As "unsafe". An example would be of how AMD GPUs some time ago didn't free a programs' last rendered buffers and you could see the literal last frame in its entirety. Fun stuff. Could've been clearer above.
            • yuriks 10mo ago
              That is not a memory leak though! That's using/exposing an uninitialized buffer, which can happen even if you allocate and free your allocations correctly. Leaking the buffer would prevent the memory region from being allocated by another application, and would in fact prevent that from happening. This is also something that Rust does protect against in safe code, by requiring initialization of all memory before use, or using MaybeUninit for buffers that aren't, where reading the buffer or asserting that it has been initialized is an unsafe operation.
              • deleted 10mo ago
                [deleted]
              • spookie 10mo ago
                Fair, bad example.
              • jmalicki 10mo ago
                It's a security hole. Rust doesn't prevent you from writing unsafe code that reads it. The bug wasn't that it could be read by a well conforming language, it was that it was handed off uninitialized to use space at all.
    • embedding-shape 10mo ago
      There are definitively people in the ecosystem who peddle sentiments like "Woah, Rust helps so much that I can basically think 'if this compiles, everything will work', and most of the times it does!", and that's the confusing part for many people. Examples found in 30 seconds of searching: - https://bsky.app/profile/codewright.bsky.social/post/3m4m5mvn6r22b https://bsky.app/profile/codewright.bsky.social/post/3m4m5mv... - https://bsky.app/profile/naps62.bsky.social/post/3lpopqwznfs2g https://bsky.app/profile/naps62.bsky.social/post/3lpopqwznfs...
      • littlestymaar 10mo ago
        > "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).
      • spoiler 10mo ago
        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.
      • muixoozie 10mo ago
        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
        • binary132 10mo ago
          There is no hint of irony in the linked posts.
  • LtdJorge 10mo ago
    Yes, that's a very common misconception. Of course, if your program compiles, that doesn't mean the logic is correct. However, if your program compiles _and_ the logic is correct, there's a high likelihood that your program won't crash (provided you handle errors and such, you cannot trust data coming from outside, allocations to always work, etc). In Rust's case, this means that the compiler is much more restrictive, exhaustive and pedantic than others like C's and C++'s. In those languages, correct logic and getting the program to compile doesn't guarantee you are free from data races or segmentation faults. Also, Rust's type system being so strong, it allows you to encode so many invariants that it makes implementing the correct logic easier (although not simpler).
    • wakawaka28 10mo ago
      >In those languages, correct logic and getting the program to compile doesn't guarantee you are free from data races or segmentation faults. I don't believe that it's guaranteed in Rust either, despite much marketing to the contrary. It just doesn't sound appealing to say "somewhat reduces many common problems" lol >Also, Rust's type system being so strong, it allows you to encode so many invariants that it makes implementing the correct logic easier (although not simpler). C++ has a strong type system too, probably fancier than Rust's or at least similar. Most people do not want to write complex type system constraints. I'm guessing that at most 25% of C++ codebases at most use complex templates with recursive templates, traits, concepts, `requires`, etc.
      • simonask 10mo ago
        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.
        • sunshowers 10mo ago
  • alkonaut 10mo ago
    "If it compiles it works" isn't true. But "If it compiles it won't eat your homework" sort of is.
    • embedding-shape 10mo ago
      Neither are true, `std:fs::remove_dir_all("/home/user/homework")` will happily compile and run, no matter if that's what you wanted or not. Rust programs can't know what you want to do, period.
      • throwawayqqq11 10mo ago
        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.
        • wakawaka28 10mo ago
          >They certainly know that you dont want to process garbage data from freed memory. It depends on what you mean by "freed". Can one write a custom allocator in Rust? How does one handle reading from special addresses that represent hardware? In both of these scenarios, one might read from or write to memory that is not obviously allocated.
          • ameliaquining 10mo ago
            Both of those things can be done in Rust, but not in safe Rust, you have to use unsafe APIs that don't check lifetimes at compile time. Safe Rust assumes a clear distinction between memory allocations that are still live and those that have been deallocated, and that you never want to access the latter, which of course is true for most applications.
          • brooke2k 10mo ago
            You can indeed write custom allocators, and you can read to or write from special addresses. The former will usually, and the latter will always, require some use of `unsafe` in order to declare to the compiler: "I have verified that the rules of ownership and borrowing are respected in this block of code".
  • MrJohz 10mo ago
    I think the key idea is that Rust gives you a lot of tools to encode semantics into your program. So you've got a much greater ability for the compiler to understand your semantics than in a language like JavaScript (say) where the compiler has very little way of knowing any information about lifetimes. However, you've still got to do that job of encoding the semantics. Moreover, the default semantics may not necessarily be the semantics you are interested in. So you need to understand the default semantics enough to know when you need something different. This is the big disadvantage of lifetime elision: in most cases it works well, but it creates defaults that may not be what you're after. The other side is that sometimes the semantics you want to encode can't be expressed in the type system, either because the type system explicitly disallows them, or because it doesn't comprehend them. At this point you start running into issues like disjoint borrows, where you know two attributes in a struct can be borrowed independently, but it's very difficult to express this to the compiler. That said, I think Rust gives you more power to express semantics in the type system than a lot of other languages (particularly a lot of more mainstream languages) which I think is what gives rise to this idea that "if it compiles, it works". The more you express, the more likely that statement is to be true, although the more you need to check that what you've expressed does match the semantics you're aiming for.
  • treyd 10mo ago
    > Some people absolutely refuse to believe it though. Who says this? I've never seen someone argue it makes it impossible to write incorrect code. If that were the case then there's no reason for it to have an integrated unit testing system. That would be an absurd statement to make, even if you can encode the entire program spec into the type system, there's always the possibly the description of a solution is not aligned with the problem being solved.
• hsywuwuf 10mo ago
  [flagged]
  • simonask 10mo ago
    FTA: > Others think someone from the Rust (programming language, not video game) development community was responsible due to how critical René has been of that project, but those claims are entirely unsubstantiated. What is this culture war you're fighting?
  • deleted 10mo ago
    [deleted]
  • Tuna-Fish 10mo ago
    Rebe isn't blaming this on rust proponents, but on a troll he banned 30 minutes before he got swatted. Where are you getting the rust connection from?
• qouteall 10mo ago
  I want to add Contagious Borrow Issue https://qouteall.fun/qouteall-blog/2025/How%20to%20Avoid%20Fighting%20Rust%20Borrow%20Checker#contagious-borrow-issue https://qouteall.fun/qouteall-blog/2025/How%20to%20Avoid%20F... Contagious borrow issue is a common problem for beginners.
• yuriks 10mo ago
  Needs a (2020) in the title. I don't think anything major is outdated, but in particular in section 10, one of the desired syntaxes is now supported as an unstable feature but there wasn't any mention of that: #![feature(closure_lifetime_binder)] fn main() { let identity = for<'a> |x: &'a i32| -> &'a i32 { x }; }
• bigstrat2003 10mo ago
  I don't see how it's a misconception to say that a 'static lifetime lives for the life of the program. The author says "it can live arbitrarily long", which by definition must include... the life of the program. Where exactly is the error then?
  • jayd16 10mo ago
    > Well yes, but a type with a 'static lifetime is different from a type bounded by a 'static lifetime. The latter can be dynamically allocated at run-time, can be safely and freely mutated, can be dropped, and can live for arbitrary durations.
  • enricozb 10mo ago
    I think if the compiler determines that it can drop a 'static, because nothing uses it after a certain point, it may drop it.
    • k__ 10mo ago
      How does this lead to confusion?
  • yuriks 10mo ago
    A 'static lifetime does not live for the rest of the program. It rather is guaranteed to live for as long as anyone is able to observe it. Data allocated in an Rc for example, lives as long as there are references to it. The ref count will keep it alive, but it will in fact still be deallocated once all references are gone (and it cannot be observed anymore).
  • wrs 10mo ago
    "Arbitrarily long" means "however long any code needs it to live", not "whatever lifetime a human reading the code can conceive of".
  • nickitolas 10mo ago
    "life of the program" might imply it needs to begin life at program start. But it can be allocated at runtime, like an example in the list shows. So its rather "lives until the end of the program", but it doesnt need to start life at the start of the program
• wrs 10mo ago
  My only complaint with this excellent list is that it treats "generics" and "lifetimes" as separate things. There's a reason the lifetime is inside the generic brackets. The code is generic over some lifetimes just as it can be generic over some types. As a Rust beginner I read lifetimes backwards, thinking <'a> means I'm "declaring a lifetime" which I then use. What that actually declares is a placeholder for a lifetime the compiler will attempt to find wherever that struct or function is used, just as it would attempt to find a valid type for a type generic <T> at the points of usage. Once I fixed that misconception everything made much more sense. Reminding myself that only the function signature matters, not the actual code, was the other thing I needed to really internalize. The compiler messages hinder this sometimes, as when the compiler says "X doesn't live long enough" it actually means "using my limited and ever-evolving ability to infer possible lifetimes from your code, I can't find one that I can use here". This is also (for me, anyway) a common "it's fine but it won't compile" case, where you don't have enough lifetime parameters. In other words, you're accidentally giving two things the same lifetime parameter when it's not actually necessary to require that the compiler come up with a single lifetime that works for both. The compiler error for that does not typically lead you to a solution directly.
  • estebank 10mo ago
    If you have a good repro case, I'd appreciate a bug report. Bad diagnostics are considered bugs.
    • wrs 10mo ago
      It's actually a classic and much-repeated case in Rust education: fn pick_first<'a>(x: &'a str, y: &'a str) -> &'a str { x // We only actually return x, never y } fn main() { let s1 = String::from("long-lived"); let result; { let s2 = String::from("short-lived"); result = pick_first(&s1, &s2); } // s2 dropped here println!("{}", result); } The error here is "borrowed value [pointing to &s2] does not live long enough". Of course it does live long enough, it's just that the constraints in the function signature don't say this usage is valid. Thinking as a beginner, I think part of the problem here is the compiler is overstating its case. With experience, one learns to read this message as "borrowed value could not be proved to live as long as required by the function declaration", but that's not what it says! It asserts that the value in fact does not live long enough, which is clearly not true. (Edit: having said this, I now realize the short version confuses beginners because of the definition of “enough”. They read it as “does not live long enough to be safe”, which the compiler is not—and cannot be—definitively saying.) When this happens in a more complex situation (say, involving a deeper call tree and struct member lifetimes as well), you just get this same basic message, and finding the place where you've unnecessarily tied two lifetimes together can be a bit of a hunt. My impression is that it's difficult or impossible for the compiler to "explain its reasoning" in a more complex case (I made an example at [0] [1]), which is understandable, but it does mean you always get this bare assertion "does not live long enough" and have to work through the tree of definitions yourself to find the bad constraint. [0] https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=bd5be9af6d58b1ae36efad68e99c31c3 https://play.rust-lang.org/?version=stable&mode=debug&editio... [1] https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=6ae902d81a05fa196f011912443a9c4f https://play.rust-lang.org/?version=stable&mode=debug&editio...