4 ms·

Previous discussion - https://news.ycombinator.com/item?id=11611436 https://news.ycombinator.com/item?id=11611436 And an eli5 https://www.reddit.com/r/rust/com

Previous discussion - https://news.ycombinator.com/item?id=11611436 https://news.ycombinator.com/item?id=11611436 And an eli5 https://www.reddit.com/r/rust/comments/6brtsu/eli5_nonlexical_lifetimes/ https://www.reddit.com/r/rust/comments/6brtsu/eli5_nonlexica...

nerdponx 9y ago
Is there an ELI5 for lifetimes in general? There are so many features of Rust that I have no context for and no intuition about. I also do not have a CS degree.
- freditup 9y ago
  Ha, don't worry about the CS degree - lifetimes are plenty confusing to people with a CS degree too! I think it'd take a combination of reading the theory and actually using Rust for most people to get a good grasp on them.
- staticassertion 9y ago
  No CS degree here either. Variables exist in memory, right? But we only need them for some amount of time - then we want our memory back. There are many strategies for this - Java uses a garbage collector to search through memory and reclaim parts no longer in use, C programmers manually call 'free'. Java suffers from its strategy because of the performance impact of that scan/ freeing strategy. C suffers from the complexity of manually managing memory leading to many security vulnerabilities. Rust takes this concept of how long memory should live - when it should be freed - and encodes it into its type system. Similar to how you can say 'this thing is an int and it can be added to other ints' rust says 'this thing lives this long and it can reference other things that live this long, or shorter'. Then the compiler can tell you "hey, you're trying to access something that might have been freed" the same way it would say "you're trying to add an integer to a string". This means you don't have the performance impact of the GC but you also have a compiler watching your back, telling you when you may be doing something unsafe. The algorithm used to determine how long variables live and when they can / can't be accessed is the subject of the RFC.
  - bluejekyll 9y ago
    Excellent description. I really like the section of "Thinking in Scopes" in the Book that describes this: https://doc.rust-lang.org/book/first-edition/lifetimes.html#thinking-in-scopes https://doc.rust-lang.org/book/first-edition/lifetimes.html#... You can think of lifetimes as hidden variables defined by the compiler that are in a sense bound to some block of code. I find this to be the best way to think of them personally.
  - yorwba 9y ago
    Nit > 'this thing lives this long and it can reference other things that live this long, or shorter'. should be '... or longer '. The reference only remains valid if the referent hasn't been dropped in the meantime, so it can only reference things that outlive it.
    - staticassertion 9y ago
      Thanks, unfortunately I can't edit the post. :(
    - deleted 9y ago
      [deleted]
  - Twirrim 9y ago
    Possibly a stupid question, but is this a bit like reference counting, like you see in python, only done at compile time?
    - mathw 9y ago
      Not really. Rust has an idea of "borrowing" references to things, which could be seen as increasing the reference count, but it's not a particularly good analogy because borrows actually have no effect on the original lifetime. So, if you borrow something and try to store it somewhere with a lifetime the compiler thinks is going to outlive the lifetime of the thing you borrowed, that's a compiler error, whereas in a reference counted language or a GCed language the original entity just keeps existing for as long as required. This is usually because said entity is on the heap - Rust puts everything on the stack by default. You can of course put things on the heap, and there is a selection of types available in the standard library which are I guess a bit like C++ smart pointers that let you have heap allocation, reference-counted semantics etc. if you want it.
- wst_ 9y ago
  Here you go: https://www.reddit.com/r/rust/comments/58rn52/can_someone_eli5_the_concept_of_lifetimes_for_me/ https://www.reddit.com/r/rust/comments/58rn52/can_someone_el...

nerdponx 9y ago

Is there an ELI5 for lifetimes in general? There are so many features of Rust that I have no context for and no intuition about. I also do not have a CS degree.

freditup 9y ago
Ha, don't worry about the CS degree - lifetimes are plenty confusing to people with a CS degree too! I think it'd take a combination of reading the theory and actually using Rust for most people to get a good grasp on them.
staticassertion 9y ago
No CS degree here either. Variables exist in memory, right? But we only need them for some amount of time - then we want our memory back. There are many strategies for this - Java uses a garbage collector to search through memory and reclaim parts no longer in use, C programmers manually call 'free'. Java suffers from its strategy because of the performance impact of that scan/ freeing strategy. C suffers from the complexity of manually managing memory leading to many security vulnerabilities. Rust takes this concept of how long memory should live - when it should be freed - and encodes it into its type system. Similar to how you can say 'this thing is an int and it can be added to other ints' rust says 'this thing lives this long and it can reference other things that live this long, or shorter'. Then the compiler can tell you "hey, you're trying to access something that might have been freed" the same way it would say "you're trying to add an integer to a string". This means you don't have the performance impact of the GC but you also have a compiler watching your back, telling you when you may be doing something unsafe. The algorithm used to determine how long variables live and when they can / can't be accessed is the subject of the RFC.
- bluejekyll 9y ago
  Excellent description. I really like the section of "Thinking in Scopes" in the Book that describes this: https://doc.rust-lang.org/book/first-edition/lifetimes.html#thinking-in-scopes https://doc.rust-lang.org/book/first-edition/lifetimes.html#... You can think of lifetimes as hidden variables defined by the compiler that are in a sense bound to some block of code. I find this to be the best way to think of them personally.
- yorwba 9y ago
  Nit > 'this thing lives this long and it can reference other things that live this long, or shorter'. should be '... or longer '. The reference only remains valid if the referent hasn't been dropped in the meantime, so it can only reference things that outlive it.
  - staticassertion 9y ago
    Thanks, unfortunately I can't edit the post. :(
  - deleted 9y ago
    [deleted]
- Twirrim 9y ago
  Possibly a stupid question, but is this a bit like reference counting, like you see in python, only done at compile time?
  - mathw 9y ago
    Not really. Rust has an idea of "borrowing" references to things, which could be seen as increasing the reference count, but it's not a particularly good analogy because borrows actually have no effect on the original lifetime. So, if you borrow something and try to store it somewhere with a lifetime the compiler thinks is going to outlive the lifetime of the thing you borrowed, that's a compiler error, whereas in a reference counted language or a GCed language the original entity just keeps existing for as long as required. This is usually because said entity is on the heap - Rust puts everything on the stack by default. You can of course put things on the heap, and there is a selection of types available in the standard library which are I guess a bit like C++ smart pointers that let you have heap allocation, reference-counted semantics etc. if you want it.
wst_ 9y ago
Here you go: https://www.reddit.com/r/rust/comments/58rn52/can_someone_eli5_the_concept_of_lifetimes_for_me/ https://www.reddit.com/r/rust/comments/58rn52/can_someone_el...