Video

Best lifetime video ever!

Thanks for the video. New to Rust as I'm trying to go through a codebase written in Rust. The shear amount of syntax in Rust is overwhelming tbh. This cleared some bits

Is this how wasm works too?

still waiting for the struct lifetimes vid!

Brilliant!

Do you know what is 醍醐灌顶 in Chinese? Your video is😀😀.

Re-inventing the wheel trying to fix a problem by making the implementation overly obscure.

shouldn't the input parameter outlive the output parameters since the output references the inputs?

8:28, hold on, ch10 of the book says it's the *shorter* of the lifetimes of x and y the example that makes me think this model is wrong goes like this: say you replaced x and y with Strings so that they aren't `static lifetime and if you tried to use l1 after making x go out of scope (and its memory was cleared), it'd still give you an error, even though it points to data owned by y, which would still be valid modeling 'a as a set of memory that l1 can point at, which contains both 'x and 'y, seems to contradict this: that would imply 'a is valid when 'x OR 'y is still valid, but the book says it's while 'x AND 'y are still valid which one is actually correct? I trust the book more than this

As a pretty senior developer coming to Rust, this explanation in terms of memory was really helpful to grok the concept. Nice examples, clearly annotated too!

The moment I knew for sure that I now understand lifetimes was when I was contributing a PR to the bat project on Github. I had to modify a function so that it takes an iterator of a tuple of two references, one of which is a struct with a distinct lifetime parameter, extract a &str from this struct, then collect and return them in a HashMap (it's confusing, I know). Rust analyzer yelled at me the first time I saved, but didn't provide a fix. I thought briefly about what the two lifetimes actually meant, typed out `'t: 'r` along with a comment that explained why, hit save and it worked. It's just one simple line but to me it was a very significant milestone. I've been writing Rust for 4 years and counting (3½ at the time of this PR), and writing that line (and more importantly, fully understanding what it's doing and why it is so) was the singular moment when I was able to say to myself, "huh I'm actually reasonably competent in Rust now".

There's a strong path-dependency to how we've ended up in "registers are faster", I think(and I was aware of that before the video, though it's a great explanation of why); register architectures are intuitive when computers are viewed in terms of arithmetic processing, and they map well to local variables. Therefore we have hardware that engages with that, provides a lot of enumerated registers, and asks for languages to utilize all of them, and that has a consequence on VM design, since the VM's goal is to remap program description to efficient hardware utilization: if it looks stack-y, then the JIT rewrites it to register-y code. On the other hand, the CPU architecture can avoid this and do something like Minimal 64x4, a non-pipelined hobby computer using discrete logic: it achieves very good performance at a relatively low clock rate by reducing the register set and optimizing the instruction set around zero page memory(a construct which exists on 6502 as well, but is used supplemental to registers), thus algorithm descriptions are smaller and the total sequential work is smaller than on other 8-bits, despite having a lower "MIPS" rating. I believe the distinction between VMs would be relatively less important on Min 64x4 because the stack VM's instruction set would also benefit from the ability to code random access efficiently. I've started to think that local variables are worth questioning, though. They serve a certain "black-boxing" purpose of presenting short routines as a matter of loading up the registers in an initial state, doing the computation, and then writing that back using the stack as a protocol between that routine and the rest of the program. But the usual alternative to a stack protocol is a buffer, and buffers have certain benefits in terms of coordination of resource use. If the buffer were implemented like a ring buffer and the computer optimized around that, it presents ideas like the Mill computer's "belt", an interesting concept, albeit one that sadly still hasn't shipped anything.

This is awesome, you have a way of breaking down complex things and using comparison that resonates with me. Looking forward to the borrow checker video.

This video explaining Rust's lifetimes is the best I've seen! Looking forward to more from you! Keep it up!

Thank you, this video is a life-saver.

man, what a great video. subscribed! 100k subs with this level of quality content is inevitable.

Still dont understand completely but the regions of memory example is far easier to understand

Great video! Keep it up

Pretty good video man!

you did a good job on this one! what do you use to create / edit your videos?

Really nice video, man, it helped improving my understanding of lifetimes. Thinking of memory regions made more sense to me.

Excellent, clear and concise! Thank you!

Duddeeeeee! You are awesomeee!

...no, with bigamism...

Newbie here, struggling (of course) with Rust concepts. I really like your alternate approach to understanding lifetimes. It helped me a lot.

Amazing explanation and presentation. Keep 'em comin!

But wouldn't a lifetime be atleast the same size as the largest sub-lifetime, instead of larger than the largest?

Very nice alternative view on lifetime understanding, I'll try to apply it in my day to day Rust thinking and see how it helps! Bravo 👏

Great video 🤘🏽🤘🏽

You really helped me out with this one. Thanks.

Very clear! Thank you

wonderful lecture! thanks

Very nice!

here how the 'r can point to &x or &foo while x out of scope? 5:40

Great video. Love the comparisons of various stages of IR at the end. Since this video has come out, godbolt has added the ability to do this!

13 And no man hath ascended up to heaven, but he that came down from heaven, even the Son of man which is in heaven. 14 And as Moses lifted up the serpent in the wilderness, even so must the Son of man be lifted up: 15 That whosoever believeth in him should not perish, but have eternal life. 16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life. 17 For God sent not his Son into the world to condemn the world; but that the world through him might be saved. 18 He that believeth on him is not condemned: but he that believeth not is condemned already, because he hath not believed in the name of the only begotten Son of God. 19 And this is the condemnation, that light is come into the world, and men loved darkness rather than light, because their deeds were evil. 20 For every one that doeth evil hateth the light, neither cometh to the light, lest his deeds should be reproved. 21 But he that doeth truth cometh to the light, that his deeds may be made manifest, that they are wrought in God. (Jn.3:13-21)

Very useful, thank you.

Great video! Thanks!

I'm suddenly very thankful for monads, which would explicitly require the programmer to say which result they really mean, but you get the option of either. In Haskell, we have `read a <&> (+) <*> do { modify (+1) a; read a }` giving 3, and `read a <**> (+) <$> do { modify (+1) a; read a }` giving 4. What perhaps is not apparent is that the "correct" semantics for both just falls out of the type system. I can directly translate the first into a more familiar syntax `*a + { a += 1; *a}`, but the second would require me to take advantage of the commutativity of addition `{ a += 1; *a } + *a`. The reason why the two sides flip around is because `(<**>) === flip (<*>)` and `(<&>) === flip (<$>)`, where `flip` exchanges the order of the first two arguments. The types of these operators are not symmetric in their arguments, so you can know which one has to be which.

You have pretty eyes.

I will try to use that model in the future let’s see how it goes. Having some more examples would be helpful in those videos I think

great little video, thanks!

Just getting into rust and one thing I wish was clearer was a way to cleanly tell the compiler "this reference will be valid during this scope" i.e. fn foo(bar: impl Iterator<Item = &my_struct>) does not compile but for some reason fn foo<'a>(bar: impl Iterator<Item = &'a my_struct>) does compile and I don't really understand why that lets the compiler accept it I appreciate that this lets it compile but I haven't guaranteed any information about that reference, only named it, but maybe this will enforce that the references in the iterator cannot go out of scope during this function call, if that is the case then I wish that was more obviously written in the lifetimes documentation.

Great video! I think a very important note about ‘static is that it also refers to owned values when used as a trait bound. That tripped me up when first learning, thinking I effectively required leaked resources if adding that bound

The region concept is confusing (an error?) at 8:40 and 10:23, The outer region means the shortest lifetime of a set of inner regions - calling this relationship using set and subset is the problem: the outer lifetime should be a subset of the inner lifetime. Both the box drawing and subset mean exactly the opposite: outer is a subset of any inner.