This Is How Rust Stops Memory Leaks

Just a small nitpick: the "Good Rust" code at 04:00 doesn't compile since you'll need to pass `&mut s` instead of only `&s`. But otherwise it's good!

5:12 can be referenced multiple times if the variable is not referenced as mutable.

Rust does NOT prevent memory leaks. You can introduce them accidentally via cyclic references when using Rc or Arc. There is also a dedicated function in the standard library, see std::mem::forget

Nitpick: What you are calling static memory allocations (stack allocation) is actually automatic memory allocation. Static allocation is for variables whose lifetime is the lifetime of the program.

Straight and to the point! Small nitpick: you can assign to the same name since the old name is no longer valid. No need to append numbers or invent new monikers.

I think there's a little bit of conflation here between "use-after-free" bugs and "memory leak" bugs. The former lead to full-blown undefined behavior, which is a common problem in C and C++, and the way Rust prevents them with ownership, borrowing, and lifetimes is truly new among mainstream languages. The latter lead to gradual memory exhaustion, as you described in the video, but the way Rust prevents them isn't new. It's actually almost identical to what (modern) C++ does. In both Rust and C++, heap memory leaks are prevented by making sure every allocation is owned by some object(s) on the stack(s) that will eventually run a destructor to free that memory. Rust's Vec/Box/Arc are very close mirrors of C++'s vector/unique_ptr/shared_ptr.

Most of the code examples in this video won’t actually compile. The very first example uses a never return type yet it returns just that it returns no data. Also there is an example where you pass an immutable reference to a function that expects a mutable reference

Yeah but C is still awesome

0:10 "in a couple of edge cases". Well since there is no "free" anywhere, these couple of edge cases are 100%

Hey man, I really appreciate these videos. One thing that I think could make them even more helpful to beginners (like me, at least with Rust) is to either highlight or animate specific sections of text when referencing jargon-heavy syntax explanations. If you highlighted each part of the syntax when describing what was going on, it would allow the video to also help people learn the language itself rather than just its features. Lmk what you think :)

This makes me appreciate automatic pointers from CPP. They use reference counting and the destructor frees memory when going out of scope.

Thanks for explaining that implicit "drop()" function. That explains a lot about the limits on where you can pass variables/data around. It makes sense in hindsight, but I would probably not have waded into the docs to find this. As rather much of a noob to low-level languages and under-the-hood data management concepts.

About the Double Borrow: you can borrow as many time as want, but you can only borrow mutable once

Thanks for posting this one. I'm enjoying as your stepping into Rust for the embedded world. It's something that I've been interested in digging more into, but it's been a struggle at times.

all I got from this video was that rust forces you to use good habbits.

The code presented at 00:05 is so bad that the title should be "This is how Rust Stops People Who Dont Know C from using C" (I'm not even sure it works in normal cases, let alone corner cases)

Leaking memory is not always bad: depends on the situation. There are ton of cases where you don't care about freeing memory (for example programs that allocate memory on startup and then terminate without freeing it). Also, if you are doing a ton of dynamic memory allocations, you are doing something wrong. Dynamic memory allocation should be seen as the last resort, and prefer static allocation or stack allocation if possible. I write firmware and it's not unusual to not use dynamic memory allocation at all (in some safety critical contexts it's a requirement). And if dynamic memory allocation is use you typically allocate the memory that you need in the bootstrap of the firmware and then don't free it (continuing to free and allocate memory risks of fragmenting the heap)

05:20 What you said about not being able to have two borrows coexist is not fully true. In Rust, you can have either 1 mutable reference on scope, or multiple inmutable/simple references to the same variable.

Back in the days I started it was assembly code and any issue was my fault. I was able to transition to coding in C without memory leaks very easily coming from a completely unforgiving start. I still prefer C although Objective-C with ARC (automatic reference counting) and Swift extensions to support stronger typing has made ObjC my favorite high-level language. (And I've coded in a bunch of them) I don't like Swift at all, not enough information visible in code.

Well simply make sure you are aware of every dynamic allocation you make and make sure that you free it when you stop using it, it's not really a problem if you know what you are doing