วีดีโอ

This is the video I wish I saw when I started with rust

I tried the code in the minute 15:00 myself, and using compiler explorer like in the video found that this rust UB does not happen anymore from rustc 1.75.0 forward. Can anyone else confirm this as I dont seem to find the explanation specified in the 1.75.0 update change log.

Nice vid but you sound like you're on cocaine

Very nice explanation . Really appreciate that

Hey, how did you make these slides? Seems like a great way to explain programming concepts!

brilliant way of presenting the nuts and bolts, thank you 👍

It would probably be undefined behavior in C if you declared x and y as restrict pointers, that tells the compiler x and y cannot be aliased so it optimizes accordingly and always return 42

Before I started using Rust, I thought it was a bit of a cult. Well... I'm afraid I've become a cultist...

Amazing explanation, thanks!

great video.

came after seeing your "Shameless self-promotion :) th-cam.com/video/OQTwvycftJU/w-d-xo.html"

this is exactly the content i am looking for! incredibly well put together, thanks for this mr O'Connor :)

Great job!

Excellent tutorial! I like that you not only explain how the Rust features work and why they work that way, but you also give examples to show the reasons that they work the way they do. This is the clearest explanation I've seen on the topic.

The perfect Rust video doesn't exi-

Python and Rust are completely different animals for completely different purposes, and they'll never compete with one another. Python is great for interactivity, learning, and easy-to-make scripts, when clarity and accessibility are important. It also has a lot of libraries. Rust is good for memory-safe and quick programs, but it's too complex and distracting for a learner and not interactive. Python is GC, Rust isn't. Python is mature and Rust isn't. Python is OO and Rust isn't (really). Don't compare apples and oranges.

57:54 is the reason why the whole complaning about "undefined behaviour should be defined" makes absolutely no sense. It just stems from lack of understanding of how an optimizing compiler works in detail. There is no useful way to define undefined behavior.

That's the video for all the ignoramuses that claim that Rust is overcomplicated. No, Rust is exactly as complicated as the problem that it's solving. Many people write undefined behaviour in C without ever knowing it, all it takes is one recast. Not to mention the absolutely ridiculous performance hit that comes from poor optimization coming from pessimistic aliasing analysis. Yes, you don't run into that sort of an issue often, but in larger code bases you inevitably will run into a problem like this. And it can literally take weeks to track down.

very true. thank you :)

Love you!

27:00 Rust, like everyone else, does *not* guarantee cleanup code will be called correctly every time. It will in this case (as with any RAII language) but `std::mem::forget`, `Box::leak`, and reference cycles are all possible in safe Rust.

Good job not being red in this video ;) (Also, great video as always!)

except no one can read it

except no one can read it

In python there IS SPECIFCLY with for the reasource issue and its quite nice. No need to pretend thst this is something we run into because it's not actually a thing in python

💪

For the Rayon example, did you consider talking about parallel folding/reducing as an alternative to mutexes? It's faster (I think?) at the cost of learning how to use a functional approach

gonna need this version for the mutex part from the original talk :D

brilliant

Been a huge fan ever since you released the tutorial on lifetimes! Please put out more videos, I can't stop watching them!

❤️

Just to interject that there is already a pretty decent rust interpreter named evcxr. Nowadays I use it as my bash replacement whenever a script starts to get too complex.

Re the pathological example around 24:00: This is a consequence of Stacked Borrows rules. Stacked Borrows is overtly strict, since it wants to allow the optimizer to always _add writes to mutable references._ Therefore, it does a "fake write" whenever such a reference is created, and this fake write means the shared reference must die (since otherwise adding an actual write is wrong). As you point out, this is often unintuitive, since no actual write happened. Tree Borrows, the alternative aliasing model for Rust (that we really need to add to the playground) is more lenient. There, your pathological example is not UB. But it loses some optimizations about writes. Which of these will be the official one in the end is as of yet undecided.

Wooow I never thought before that generics in rust include the lifetime with the type. that's a great insite that was completly missing from my understanding thanks alot for this!

Having the drop function just an empty function is badass. That is so cool that I no longer hate Rust. But I still like C++ more❤

In 32:17, you say you think the casts [from `(int *)` to `(Foo *)`] are allowed. That's true, since any casts between data pointers are allowed (as long as there are no alignment or similar issues; let's ignore that part). However, I think the same rule of the previous example applies: You cannot access the data through that pointer. You must cast back to `(int *)` before dereferencing. So, the access to `foo1->y` is already illegal (access through a wrong type) even if you would remove the other (partially-overlapping) write.

Wonderfully 'simply explained' 🙂

I've written a lot of C++ and C. Perhaps too much, because I understood the "pathological example" almost immediately - in the sense that I opened up the playground and every experiment I made came out exactly as predicted, which was a a funny experience because I've barely ever touched Rust, and never Unsafe. But if you're used to thinking about what is- and is-not UB in C/C++ and what optimizations you're hoping to achieve when you use the Restrict keyword (and how Restrict shenanigans can quickly turn UB) then the Rust example almost explains itself. I'm glad you showed it to us, this is really good stuff. EDIT: C.f. the bit about a "false positive" in the borrow-checker - I'm glad you illustrated that "I wish the borrow checker would allow this" is functionally equivalent to "I wish the compiler was less certain about pointer providence so it would be forced to write slower code."

Lifetimes are extremely frustrating for a long stretch of the Rust learning curve, but the moment you finally get it is truly a wonderful experience. That moment for me happened when I was submitting a major PR to the bat project last year, where I had a function that takes an iterator of 2-tuple of two references, one of which is a struct with a distinct lifetime parameter, and returns a hashmap with a reference as the key. It's quite a mouthful but the details aren't super relevant. So I had this feeling that there was going to be a lifetime issue when I wrote the function without explicit annotations, despite RA not immediately yelling at me for it (there were other outstanding errors; lifetimes are checked last). Indeed there was an error, but I wasn't scared or confused because I understood exactly what the issue was. There were four places that needed explicit lifetimes: three in the input iterator and one in the output hashmap. I annotated them appropriately with two lifetime parameters, then very confidently added an outlives bound. And the error went away. `'t: 'r,`. It was less than ten characters but words can hardly describe my immense self-satisfaction. If there is such a thing as "my proudest single line of code", this would be it because it encapsulates the mastery of a very difficult concept. At that moment (or even thinking back about it now) I almost felt like an arcane wizard, if this makes any sense. It was the event after which I could tell myself and everyone, "yeah I understand lifetimes now" and by extension "I've graduated being a Rust beginner" without any imposter guilt. Anyways that's probably enough self gloating. If anyone's interested seeing the code, it's a function named `get_syntax_mapping_to_paths` in the bat repository.

Scoped threads fixes your thread example around 1:17:00 with a lot less fuss.

What is this colorscheme please?

Rust is very, very interesting, thanks for these amazing explanations

I really can't overstate how incredible this talk is (along with all the other stuff on your channel). Your clear and warm presentation style, your commitment to rigor in your explanations, and your well-crafted examples are all very genuinely impressive and appreciated. Hoping you make more educational content like this--I'll be tuning in.

Great video! Commenting for the youtube algorithm :)

That generic based demonstration just gave the answer !!!

Your examples are really good and this helped me a lot on my Rust journey. May I take your examples and present them to my team and ofc I'll credit you.

Thank you for creating this talk! This is exactly what the industry needs -- to bridge the gap between between how you did things in C/C++ and how you could do them in Rust.

42:10 wouldn't this assembly cause incorrect behavior if the int64_t pointer is pointing to two int32_t elements in the middle of the array? I guess that the compiler makes the assumption that the 64bit pointer can't point to the middle of the array because a pointer cast like that is undefined behavior (?) I don't know the rules to this kind of pointer casts, honestly

so clear explanation. it clicks instantly when you go through the problem and reach the solution. well done. thanks

I am not sure overloading Type in this way to think about lifetimes is good. It confuses me because a String and a String are the same Type. I know you add a little to try and explain that. It is appreciated, but adds indirection that is ultimately confusing. I understand why T & T was fine, that makes sense generically. I though would not try and explain by using generics. I want to understand this way of thinking, but I find I am worse off as opposed to just knowing the element string reference has to life as long as the contents of the vector do. Straight to the point.