3 ms·

> not recognizing the implications of an extra reference here and there when the language frees things based on static detections of being unused Maybe I’m mis

> not recognizing the implications of an extra reference here and there when the language frees things based on static detections of being unused Maybe I’m misunderstanding, but isn’t the point of the borrow checker to throw errors if a reference “outlives” the memory it references? How can an extra reference extend the lifetime?

hansvm 2y ago
Rust (most of the time, I'm not arguing about failure modes at all right now, let's pretend it's perfect) drops items when you're done with them. If you use the item longer, you have a longer implicit lifetime. The memory it references will also be claimed for longer (the reference does not outlive its corresponding memory). You only fix that by explicitly considering lifetimes as you write your code -- adding in concrete lifetimes and letting the compiler tell you when you make a mistake (very hard to do as a holistic strategy, so nobody does), or just "git gud" (some people do this, but it takes time, and it's not the norm; you can code at a very high level without developing that particular skill subset, with the nearly inevitable result of "leaky" rust code that's otherwise quite nice).
- worik 2y ago
  > drops items when you're done with them. That is what GC languages do. Too You can get serious resource leaks in any language if you are careless What Rust guarantees is you cannot derefernce a null pointer
  - yawaramin 2y ago
    Sure, but that's not the point of Rust. Many GC'd languages also guarantee that nothing can be null.
- littlestymaar 2y ago
  I don't know where you got this idea but this is wrong. > you use the item longer, you have a longer implicit lifetime. The memory it references will also be claimed for longer This is only true at the stack frame level, you cannot extend a variable beyond that, and there's no difference with a GC in that particular case (a GC will never remove an element for which there's a variable on the stack pointing towards it) > You only fix that by explicitly considering lifetimes as you write your code Lifetime parameters don't alter the the behavior, and their are either mandatory if the situation is ambiguous or entirely redundant. And it only works at the function boundaries, where lifetime extension cannot happen anyway. (See above) Please stop spreading bullshit criticism that have no grounding in reality (Rust has real defects like everything else, but spreading nonesense isn't OK).
  - hansvm 2y ago
    Who said anything about extending "variables"? If you heap allocate something and store a reference to it, Rust will absolutely keep that object alive till all such references are gone. It's not "bullshit [with] no grounding in reality." That property is, yes, what you would see in a GC language (e.g., Entity Framework back in the day in C# would have a leak if you tried to create short-lived objects from long-lived objects using the built-in DI, since EF had a bug maintaining a strong reference to those objects tied to the lifetime of the outer object). My observation is that people tend to do that much more in Rust than in GC languages because the compiler makes other coding patterns harder.
    - deleted 2y ago
      [deleted]
    - steveklabnik 2y ago
      Rust does not keep variables alive until references are gone. It checks to make sure that any reference lives as long as or shorter than its referent. If the reference is longer lived than the referent, that’s a compile error.
    - littlestymaar 2y ago
      > Who said anything about extending "variables"? I did, because that's the only thing that can be kept alive longer than needed (till the end of the scope where the variable is defined). > If you heap allocate something and store a reference to it, Rust will absolutely keep that object alive till all such references are gone. No it doesn't. And it shows you have no understanding of how Rust works. A GC will do that, but the borrow checker won't, it cannot, all it can do is to yell at you so that you make your variable live as long as it needs. See this playground to see what happen when you allocate something on the heap and try return a reference to it: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=130bcebf379dbb10dd4b51e649ed83bf https://play.rust-lang.org/?version=stable&mode=debug&editio... If you could please stop spreading nonsense about a language you don't even know the basics of, that would be great for everyone.
    - MeetingsBrowser 2y ago

hansvm 2y ago

Rust (most of the time, I'm not arguing about failure modes at all right now, let's pretend it's perfect) drops items when you're done with them. If you use the item longer, you have a longer implicit lifetime. The memory it references will also be claimed for longer (the reference does not outlive its corresponding memory). You only fix that by explicitly considering lifetimes as you write your code -- adding in concrete lifetimes and letting the compiler tell you when you make a mistake (very hard to do as a holistic strategy, so nobody does), or just "git gud" (some people do this, but it takes time, and it's not the norm; you can code at a very high level without developing that particular skill subset, with the nearly inevitable result of "leaky" rust code that's otherwise quite nice).

worik 2y ago
> drops items when you're done with them. That is what GC languages do. Too You can get serious resource leaks in any language if you are careless What Rust guarantees is you cannot derefernce a null pointer
- yawaramin 2y ago
  Sure, but that's not the point of Rust. Many GC'd languages also guarantee that nothing can be null.
littlestymaar 2y ago
I don't know where you got this idea but this is wrong. > you use the item longer, you have a longer implicit lifetime. The memory it references will also be claimed for longer This is only true at the stack frame level, you cannot extend a variable beyond that, and there's no difference with a GC in that particular case (a GC will never remove an element for which there's a variable on the stack pointing towards it) > You only fix that by explicitly considering lifetimes as you write your code Lifetime parameters don't alter the the behavior, and their are either mandatory if the situation is ambiguous or entirely redundant. And it only works at the function boundaries, where lifetime extension cannot happen anyway. (See above) Please stop spreading bullshit criticism that have no grounding in reality (Rust has real defects like everything else, but spreading nonesense isn't OK).
- hansvm 2y ago
  Who said anything about extending "variables"? If you heap allocate something and store a reference to it, Rust will absolutely keep that object alive till all such references are gone. It's not "bullshit [with] no grounding in reality." That property is, yes, what you would see in a GC language (e.g., Entity Framework back in the day in C# would have a leak if you tried to create short-lived objects from long-lived objects using the built-in DI, since EF had a bug maintaining a strong reference to those objects tied to the lifetime of the outer object). My observation is that people tend to do that much more in Rust than in GC languages because the compiler makes other coding patterns harder.
  - deleted 2y ago
    [deleted]
  - steveklabnik 2y ago
    Rust does not keep variables alive until references are gone. It checks to make sure that any reference lives as long as or shorter than its referent. If the reference is longer lived than the referent, that’s a compile error.
  - littlestymaar 2y ago
    > Who said anything about extending "variables"? I did, because that's the only thing that can be kept alive longer than needed (till the end of the scope where the variable is defined). > If you heap allocate something and store a reference to it, Rust will absolutely keep that object alive till all such references are gone. No it doesn't. And it shows you have no understanding of how Rust works. A GC will do that, but the borrow checker won't, it cannot, all it can do is to yell at you so that you make your variable live as long as it needs. See this playground to see what happen when you allocate something on the heap and try return a reference to it: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=130bcebf379dbb10dd4b51e649ed83bf https://play.rust-lang.org/?version=stable&mode=debug&editio... If you could please stop spreading nonsense about a language you don't even know the basics of, that would be great for everyone.
  - MeetingsBrowser 2y ago