Hacker News Reader

Comment by the_common_man | Hacker News Reader

Previous discussion - https://news.ycombinator.com/item?id=11611436

And an eli5 https://www.reddit.com/r/rust/comments/6brtsu/eli5_nonlexica...

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.

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.

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.

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#...

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.

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.

Thanks, unfortunately I can't edit the post. :(

Possibly a stupid question, but is this a bit like reference counting, like you see in python, only done at compile time?

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.

In python you can't really statically define a reference count

   a = {}
   b = {}
   l = []
   for _ in range(100):
       if input('thingy'):
          l.append(a)
       else:
          l.append(b)

In that snippet it's impossible to know how many references there are to a or b.

In Rust, lifetime management is set up so that your code can statically determine when something no longer can be referred to (hence "free GC").

For example:

   def f():
      a = 3 
      g(a)
      # a is no longer used from this point
      return 5

you can clearly define when things are no longer usable, hence free-able. Python in this context will also free at the end of the function, but it's because it will be decrementing the reference counter and it gets to 0. But Rust won't need to have the reference counter since it knows it can free the object at any point after g.

(This isn't a great example for a lot of reasons, Rust allows you to go much further than this)

This ends up being somewhat similar to writing code in more statically typed languages/languages with dependent types. You might have to rework your code so that the machine can properly identify when it can free memory.

How then does Rust avoid the if('thingy') issue? Or, for that matter, a language like C, where presumably a and b would be allocated on the stack. In C would they both hang around until the function returns? Or would I have to copy them into the array anyway, which would be heap-allocated?

They're stack allocated in Rust too, so they're both going to stick around. Arrays in Rust are stack allocated, but this code would probably use a vector, which is heap allocated, and so yeah, you'd end up copying them from the stack to the heap.

It's more like compile-time weakrefs, where the compiler ensures that you can't access a weakref after the source strong reference is gone (not just that deref'ing the weakref returns None)

A bit. Not completely, but a bit. That analogy may well help you understand how lifetimes work, but it will break down well before you have a workable understanding of lifetimes.

Not a stupid question, as it's a very common way for some people to think about it. I don't think it's very accurate though, and leads to incorrect intuitions.

This is because reference counting is prescriptive, that is, the count determines how long a value stays alive. Lifetimes are descriptive, that is, you cannot magically make something live longer by taking an additional reference to it, instead, you'll get an error.

Not stupid at all, and something that a lot of people ask.

It's not really like that - with reference counting you sort of have multiple 'owners' of a variable, and they all get to 'free' that memory except that 'free' just decrements a counter.

With rust there is a very clear owner at all points - you always know that your code in one spot owns the memory, and no other code does. There may be references handed out but those are very clearly distinct - that is, by looking at the code you can see "yes, I own this" or "yes, I'm borrowing this".

Now, with borrowing it's a little bit more like reference counting, but it's really just scope based. We know that the references are valid for some scope, and after that scope they are not. There's no internal counting or anything like that in the compiler as far as I am aware.

Great explanation. The system also takes care of ownership moving around. In C you have functions that take a pointer to something, but you don't know who owns it (and is responsible for cleaning it up) after the function call, unless that is made explicit in the description. In Rust if you've moved ownership you can't use it in the caller afterwards, and if you haven't moved ownership you can't use it in the callee after the function has finished (this system is called borrowing, and is why the system that deals with lifetimes is called the 'borrow checker').

Actually there is another way which you'll find commonly in well written robust libraries - make the argument a const pointer, so that the callee is obviously not responsible for clearing it up and then the callee takes a copy to keep. This also allows passing both const and non const data to the same function, and means that there is much less likely to be an ownership screq-up across a library boundary. As a pattern though it can result in a lot of unnecessary copies, which Rust's system allows you to avoid.

Interesting. I have only worked in C a little bit, but I have seen the `const int foo(const int * x)` idiom a few times now.

So there is a formal sense of "ownership" of memory in rust? And right now it's based on the lexical scope in which the memory was allocated?

The checker in the compiler was being too conservative, because it was easier to write a conservative one. That means that sometimes it would complain about cases that were actually just fine. The language doesn't specify that lifetimes are tied to lexical scope, that's just what the borrow checker was using as a shortcut. The new one will be more specific.

This is sort of true, but also not: it wasn't that it was easier to write a conservative one, it's that analysis is inherently conservative, and so we chose lexical scope because, well, that's what most languages do.

The language generally does specify that they are, and that's exactly how we teach borrowing today. This new one is not more specific, but more general: it allows all programs today to stay the same, but enables more programs that don't compile today to compile in the future.

Here you go: https://www.reddit.com/r/rust/comments/58rn52/can_someone_el...

Reply on news.ycombinator.com