Big thing missing from the video is C++ objects, which could also be automatically destructed, could also be moved, could also be referenced. It's also free. On the first glance it seems like rust is no better than C++. Critical missing information here is that rust enforces these constraints, while C++ does not. I think this is the main reason why rust is better, object ownership is secondary.
I just don't consider safer as better. it's such a reductionist view. c++ is better in every way except in explicit safety. People are gonna write horrible code thinking it's safe and efficient and it's most likely not. Enums are an example where the largest variant will dictate the allocated size per entry. It looks very elegant but it's the opposite of efficient. Rust is full of this and you need to know and be mindful about it or you'll write the most bloated inefficient programs ever. If rust picks up brace yourself for mountains of truly horrible code with a certified quality label.
@@indiesigi7807 How are enums the opposite of efficient? For that usecase, you WILL need to use the maximum variant size (unless you want to suffer with malloc). The direct translation to C/C++ has the same problem: ```rust enum E { A(i32, i32), B(u64, u64) } ``` ```c typedef enum { E_A, E_B, } E_Type; typedef struct { E_Type type; union { struct { int a_first, a_second }; struct { uint64_t b_first, b_second; } }; } E; ```
The main feature of Rust is the borrow checker. C++ has unique_ptr and shared_ptr, which are analogous to owned value and Arc in Rust, but that's where C++ safety ends. In C++ invalid references are allowed, you can have multiple mutable references, can hold reference to a no longer existing value etc. C++ doesn't have any mechanism to avoid it. That's why things like use-after-free are so common in C++. Rust does provide safety guarantees for references. All references are always valid, you can't have multiple mutable references, references can't outlive values. That's why it's practically impossible to produce memory-related bugs.
@@mk72v2oqVery Good explanation. I can see why rust ensure memory safety：only *One* immutable Reference is allowed for each Object/Functor. They will be destroyed when the ref counting reaches *Zero* (I.e. Ref to obj no longer in use).
@@indiesigi7807 Rust isn't only safer, it's tooling is way better, meta-programming way more powerful, it has better (and way easier) iterators, better functional programming support, traits, abstract data types, labeled loops, almost everything is an expression (and thus composable), native async support, etc., etc. I have to find yet one(!) single thing that C++ does better than Rust!? I've been programming in C++ for over 20 years and just recently started using Rust: it's just way simpler, faster and easier to work with. It's not unusual that I can express the same algorithm with half the code in Rust.
This is amazing but not the main reason why most people love Rust. Rust like used all the good practices that have been developed by the programming community and fit into a single language, almost each Rust feature could be a reason of its own to like it. The compiler errors are amazing. Rust Enums featuring algebraic type system, offering amazing error handling system with Result type. No null values with Option types, completely eliminating an entire field of problems. It isn't object oriented but still have interfaces (known as traits) and type methods, but no inheritance (which was like the part used badly in other OO languages). And I could just go on and on. Rust took all good parts from different languages, coding styles and paradigms, but removing the bad parts about em. Rust is arguably the best one yet, still not perfect and still improving. And personally I found Rust as the best middle ground from "close to procedural" but still very expressive with functional programming paradigm.
Main is a bit of a bad example because the OS is supposed to free the memory from your program anyway. Leaks are more of a constantly running program thing.
I'd like to add onto the garbage collector explanation that there are multiple types of garbage collection strategies, Java has a mark and sweep strategy, which marks memory accessible from the running program and sweeps the rest at regular intervals. Other languages like PHP use reference counting, where memory is reclaimed as soon as nothing points to it. They each have their advantages and disadvantages.
So doesn't Smart Pointers in C++ also solve this particular problem of memory leak when variables are going out of scope? Like if we have a pointer and enclose it in a class then if it goes out of scope it's destructor will be called which will initiate the cleanup code required to free up the memory. Is it not a good enough solution or am i missing something?
Not only smart pointers. std::vector is basically an array of variable length in heap that gets freed when out of scope. It is also used in std::string and in every class that frees up resources on its destructor. It's called RAII and it was a thing in c++ before Rust existed.
C++'s safety is an afterthought and is all opt in, while Rust's safety is inherent to the language and is all opt out. That makes a big difference and reduces what code you have to consider when something goes wrong. Also, if your rust program compiles, you can be pretty confident that it will work before you even run it.
@@mghinto I don't get this mindset though? Nobody is forcing you to use the unsafe c++. Nobody is also forcing you to not use the unsafe keyword in rust. C++ is plenty fine enough. RAII is enough.
@@starllama2149 The problem is that RAII in C++ is not mutually exclusive to the old ways of doing things. Modern C++ still allows you to freely allocate memory using malloc/new, modern C++ still allows you to get a raw pointer from a smart pointer, modern C++ still allows you to mutate a value through _any_ pointer pointing to a non-const value, smart or not. You may scoff and say something along the lines of "anybody who knows what they're doing wouldn't do this", and yes, you're right. The problem is not everybody knows what they're doing, and even those who know what they're doing can have a lapse in judgement and make a mistake somewhere that proliferates and leads to swaths of unsafe code. It's not enough to just trust that everybody and anybody knows what they're doing, which is what Rust understands and IMO gets right with its safe-by-default design.
It's a question of opt-in vs opt-out. In C++, you need to actively seek the safe pattern but doing magic with pointers is often easier and less verbose. In Rust, the ownership is enforced and you need to explicitly opt-out of it to be able to play around with memory freely. Which one is a better option depends on your use-case.
@jacobpradels For static verification, many dependently typed languages like Agda are well-suited. All functional programming languages are of course memory-safe, but there are some which actually have comparable performance to procedural languages and do not necessarily use a garbage collector. I think Roc is one of them. PS: Although my initial comment sounded a bit harsh, I enjoyed your video nonetheless, I was just taken a bit by surprise by your opener ^^
Nitpicking, but rust wouldn't pop arr from the stack after the move. It's the compiler that marks arr as no longer valid. It's a compile time check, not a runtime action.
Generally well explained but left out are the MANY corollaries of Rust's philosophy such as standing on your head to get two objects that point to each other and the difficulties inherent in graphs. That you have to drag in special crates just to have a mutable global. New concepts entirely like lifetimes need to be understood, etc., etc.. I realize there are solutions to all this, but Rust requires a lot more out of the programmer than C++ does - it just does. I also realize that most Rust programmers would say that's a good thing and most of the time I'd be with them on that opinion, but to leave all this out will really not describe to a C++ programmer the difficulty of adjusting to Rust. This makes it seem like ownership is a no-brainer and "that's all there is" when, in fact, the devil's in the details.
Yes, Rust has a steeper learning curve than C++. On the other hand it's a lot less you need to learn to actually be competent. And Rust will let you know that you still have to learn while C++ will happily pretend like absolute garbage is fine. My favorite part of pretty much every C++ conference is when some speaker presents an innocent looking piece of code where even committee members in the audience can't tell why it's wrong.
Mastering C isn't just about writing syntactically correct code--it's about wielding an unparalleled command over memory management. True C programmers understand that the heart of the language lies in navigating the delicate intricacies of dynamic allocation, pointers, and memory deallocation. Efficient memory management is the core of performance, reliability, and scalability. Without it, you're merely scripting. To call oneself a C coder without this expertise is to misunderstand the true power of the language.
@@RenderingUser Assembly is like that old-school mercenary who gets the job done, but you've got to personally guide every bullet. C? It's the guy who follows orders but still might blow up half the team. Rust? Oh, Rust is that overly cautious rookie who's like, 'You sure you wanna fire that? You might hurt yourself.' Meanwhile, Assembly’s already smoking a cigar and counting the cash. Efficient, baby!
@@1n4f4bl3 Rust isnt the rookie. its more like the guy that has a 3000 page book of stratagies and wont let a plan go into action unless its detailed to perfection
@@RenderingUser Oh yeah, that language nobody used to care about. Now it's like the cool kid at the programming party, sipping its memory-safe latte while C and C++ sit in the corner reminiscing about the good ol' days when nobody cared if things blew up. Rust? Please. It’s like the hipster of languages -- 'I was safe before it was cool!'
Great video btw actually made me so curious that i would like to learn more about rust
ปีที่แล้ว +22
Surely it is because I’m an old fashioned C/C++ programmer and I can’t still see the beauty of this ownership paradigm, but right now I can only think about how annoyingly painful would be for me to try coding about anything in Rust, I already have a headache just from thinking about it. I can definitely see the advantages of of the compile time analysis and strict memory management Rust provides, but I’m afraid it comes with a cost in flexibility and usability that may be too high for certain situations.
I have a headache thinking of the uncertainty from languages that don't have a borrow checker. On rust I hardly even have to run the program. If it compiles, it works.
@@pyyrr you only focus on the borrow checker because you keep actively fighting against it. Learning to code involves learning the best design patters for a language too.
Java would NOT leave array on the heap in these examples. See "escape analysis". Java would work the same way as Rust. Of course, in compicated cases, array reference may eventually escape few scopes away and be left on the heap, but we can find equivalent example for Rust when this happens too.
Unfortunately I’m stuck modifying a C++ codebase, it’s a shame because I’d love to use Rust but I don’t have the time to rewrite this entire framework in Rust 😂
Shared pointers have a slightly higher runtime cost than the ownership model since a counter has to be incremented / decremented with every call. The upside is that shared pointers and weak pointers are wayyyy less restrictive.
@@Biriadan can you clarify what do you mean by restrictive? also the last part he explained sounds just like unique_ptr and std::move to me. well I guess not if its owned by multiple at the same time.
@@zanagi I can have multiple pointers to the same block of memory and be able to mutate it from any of them without any special constructs needed at all. I think to get the same write many behavior you need to use special constructs in rust like rc and arc.
Nice video, I'd like to share how this 2:53 is similar to how C#'s span works, the span is automatically freed when it exits the scope. { var array = new int[10].AsSpan(); } // The array is dead now, no heap allocations, no GC. 🚀 You could also just allocate on the stack (via stackalloc), but that is not a good idea for bigger arrays.
It can’t be the best unless it does all that, but was simple. Instead it’s complex with a steep learning curve. That’s not a small issue, people don’t run companies don’t understand the value of being able to move quickly.
first, they told me to respect ring zero. then they told me to respect women. now they tell me to respect memory. but there was no one left to respect me
I'm building a programming language dose dose reference counting at the compilation level public and static -- exposed one immutable the other not , local -- stack and private I maintain memory buy counting references during compilation when references hit 0 it's unallocated (done right after the last reference is nulled ) it dose have self-referenece issues of which the complier will have to figure out
@@sot_dev RAII is automatic in C++ though. That's the whole point, you don't have to think about it. If your class has a smart pointer, or other object with RAII, the class will have it's destructor automatically generated. The only time you need to write destructors yourself is when wrapping C code, just like Rust.
I prefere c cause any type has the freedom of being entirely allocated on the stack, static heap or dynamic heap. I also like treating bools like ints and inlining my logic into jump tables using 2d matrix of of function pointers so false false is [0, 0] true false [1, 0] or true + true and false + true is [2, 1] I think rust is great for low level embedded applications but not for drivers and systems programming.
becuase in rust a block of memory has one owner. if you want that same block of memory to have two owners, or shared ownership you can use rc or arc (for multithreaded) it gets even weirder because this type of owner ship gives you a read only access type. if you need to be mutable as well you need to use refcell, and when using arc (for multithreaded) you usually would use a mutex, theres rwlock which i never used so idk about it theres probably alot more.
But the system could store a value in the heap along with the allocated data to store the number of references to that address and every time the ownership is duplicated the number increases, every time a reference is released, the number decreases and when the last reference is released with the value equal to 1, the heap data would be deallocated once and for all. What would be the consequences of implementing this and what problems that a gc would solve that It can not solve?
I mean, I like Rust, but sometimes I don't need these restrictions in my way. I would prefer the freedom of C. Besides, there are analyser tools that can help locate potential memory leaks. The beauty of C is that one can imagine what the assembly code would look like behind the scenes, with Rust's abstractions it would be more difficult. You pay with overcomplexity for just not having to free memory yourself. All you have to do is use tools that help you locate problems in the code where memory leaks could be, OR design your C code that way so you don't have memory leaks (so that you know for sure where all allocations and deallocations are). With Rust you would still have to design your code to comply with borrow checker anyway. Rust could be a language for perfectionists, but you can still be one using other languages.
@@Jardynq when you develop in C, the main "borrow checker" should be in your brain. Good architecture and code design will solve these problems at early stage of development, and perhaps even save you from using tools for too long (depends on the project scale). Rust forced slightly different way of coding becuase of the language design, and this could create a new set of logical problems that you would still need to address. Take Linked List implementation in Rust for example. I don't need this protection that Rust forces, I need full control. I guess Rust is really needed in those cases where programmers can't protect themselves from making mistakes. I really don't like the idea of such fundamental restrictions that force me to write code in some other way, not the way I want it to be written. No language will take away my freedom. Rust can be still used for critical parts when and if I choose it as a tool for the task. But becoming pure Rust evangelist is not going to happen.
Where can you learn this kind of topic? I feel like, i'm still missing a lot of information that i should've know. I want to understand more the java lang. Where should i start?
@@cluelessProgrammer1 google or talk to ChatGPT. “How does Java handle memory management?” Then compare it to other languages. Likely the answer you get will prompt more questions “What is a stack?” “What is a heap?” “How is memory allocated on a stack vs heap?” If you just ask a few questions then ask about the things you don’t understand you can learn a ton
Now, I’m probably missing something, but why not just… share ownership? When an owner is removed from the stack, it or an intermediary just double checks there are no other owners before unallocating it. Yes, this requires storage to know the other owners, and possibly an intermediary process, but given you could using something like a hash table to store this minimal data compactly and quickly accessible, and the intermediary process (if it exists) would only be executed when needed, instead of constantly. Would this not minimally impact the efficiency of the concept, but remove all the drawbacks of switching ownership and multi-scoped variables? At least to me, this functionality concept of this seems to fundamentally break scope inherited variables in closures, which sounds terribly annoying.
This would be referenced counting instead of ownership. Rust also has that with `Rc` but it does use a lot more memory and may even be really dangerous when doing multi threading when releasing both Rcs thats what Arc is for, a thread safe version of Rc with essentially a mutex to change the inner rc. correct me if i'm wrong.
Great question! I really appreciate questions like this and I think it highlights something I forgot to mention in the video which is that one of the big benefits rust provides here is the ability to do this checking at compile time rather than runtime. And this allows for catching various kinds of bugs before code can even be built. The solution you mentioned sounds very similar to reference counting. I’m far from an expert in language design, but there are trade offs when you move in either direction.
Thanks for the informative answers! I’m not entirely sure why that wouldn’t be the default, but there probably is a good reason. I’ve been meaning to learn rust, if nothing else learning about this more might be a good reason to startx
You can share immutable refenece easily in Rust, also you can "borrow" someting for a moment, all static at compile time. If you need runtime safe sharing there also many ways but the are explicit in Rust, explicit in function and additional cost.
Rust’s strict ownership rules can sometimes lead to inefficient patterns when compared to languages like C, where manual memory management allows for more granular control. For example, Rust may require clones in certain situations to satisfy the borrow checker, which can lead to performance overhead.
If you really need a raw pointer, unsafe rust exists. the difference is, you can limit the unsafe code to very reduced sections, and make the api safe externally.
I too pray to the god of safety. Even people with the best intentions run into the sea, that's whyI wear a life vest. Only thing I refuse is to debug. Not part of programming for me and I hope I never encounter such a situation.
Before posting such a ridiculous claim, you should have checked the RAII. This makes your Rust so cool, to destroy something when goes out of scope. C++ smoked this long time ago. Rust has better implicit move semantics management in compiler. But RAII is C++
Rust did not introduce the concept of ownership. It's just the first performance based compiled language to come out in a long time that *also* facilitates ownership. And what... do you think you get this all for free? What you're sacrificing is the overall design and maintainability of your program since you become burdened by its approach to ownership rather than being able to implement your own.
@@antifa_communist "Someone has a position I disagree with so it must come from a position of ignorance". I'm not even surprised someone who bears the name "antifa_communist" thinks like this. Grow up.
Actually, you picked a really poor example at the start. The issue is not with programs that just forget to clean up resources and then exit. The kernel keeps track of heap allocations and once the program terminates it just frees that memory right up. This is technically a memory leak, but it has no effect on a modern operating system. While this is not best practice, this is perfectly safe and fine to do. What you should have gone with are applications like Kernel Modules or Daemons that continually run in the background but never use free() to give back memory. Those are a much bigger problem as they constantly call for more and more resources, but never free them. This will, over a long enough period, cause an _actual_ memory leak. And to be completely honest: Rust fanboys WAY over-hype memory leaks. Worst case the Kernel denies the resources and you get an error which crashes the program and frees everything anyway. Rust fanboys really need to stop acting as if memory leaks are a thing that every application needs to care about. In 95% of applications you won't even notice that they occur. Yes, those 5% of applications benefit from it, but that is no reason to rewrite all of the programs in Rust.
@@antifa_communist I am not saying Rust is not used anywhere. I am saying when you try to use it on real project it becomes a lot more challenging to write Rust code. Even though the companies you mentioned use Rust, its part must be about 0.001% of all their code.
@@antifa_communist perhaps you should think before you start saying even dumber things. obviously nothing is "moved," ownership is just changed in memory. The problem is that the values you would normally get from the original variable are no longer accessible from that variable, and instead appear to "move" to another variable. i.e. the psuedocode "a = [0, 1, 2]; b = a;" would "move" ownership of the array from a to b, resulting in a having no value.
I don't really get the obsession with Rust's ownership model, yes its cool and almost always promises the programmer to handle memory deallocation in the end of the scope, but... combined complexity of other things in the language like enums that can hold values , Heap based types (Rc, Box,Arc,etc.) or Macros make it unbearable to quickly develop things. Problem that nearly everyone point at, of: "bug because of use after free" or "forgot to free() in C, unsafe!!!!" aren't as much of a deal as the unnecessary complexity of doing literally anything in the language. It could've be the case, if there where no debug tools, valrgrind or bounds checking in all of the system programming languages for decades. I doubt that you need majority of the features (even core one) in rust to make "safe software".
what is ti with rust programmers i've never seen similar weird community of a programming language, i've used rust for 2 years along side C/python and Go recently, it is : a simple language + "best practices" enforced by the language anyone can by choice implement those concepts in any other language . for example all languages have mutex, rust enforces mutex wrappers on mutables to avoid lock-ins (you forget to unlock) the same wrapper could be implemented in any language in 10 lines of code only rust ENFORCES IT ON YOU and calls it a feature, get over yourself just learn the concepts and use any language you feel productive using (5% performance increase doesn't matter in 99.99% of your projects) by the way none of rust "best practices" are invented by rust team all are known techniques from 70's and 80's long before they were even born
"none of these things was invented by rust" Funny how you'd say that when rust is unlike most other popular languages. Sure it existed somewhere in random languages. Rust put it all together and streamlined it.
It actually does. What you mean, I believe, is that it cannot prevent you from deliberately causing a leak (and obviously! given that it includes mem::leak()). But it definitely prevents inadvertent leaks in almost all cases by tracking ownership and dropping where required. That's what is meant, not that it's literally impossible to cause a leak.
It protects you from certain classes of memory leaks. Of course you can still use a Vec or HashMap improperly and have memory bloat, but those are more of logic problems than random footguns. It's not perfect and it was never meant to be.
Garbage collection is hard, so Rust pushes memory management issues onto the programmer. While this speeds up execution time, it slows up development time. I would rather devote my mental energies to the problem domain than concern myself with the complexities of memory management.
Development time is slowed down due to uncertainties that require extra runtime bug fixing. In rust, if it compiles, it works. If you don't want to deal with the complexities of memory management, don't use a compiled language
No memory management isn't hard. Free the space. Why do you need some fascist language to enforce what decent programmers ought to be doing. Also, memory leaks may or may not be an issue in a program. It is inefficient and not good practice but depending upon the task it may or may not be an issue. Trading simplicity for complexity is not always the best solution.
There are many reasons why you might not free the space. You might forget for example. You don't understand Rust at all. Comparing it with fascism is laughable.
Big thing missing from the video is C++ objects, which could also be automatically destructed, could also be moved, could also be referenced. It's also free.
On the first glance it seems like rust is no better than C++.
Critical missing information here is that rust enforces these constraints, while C++ does not. I think this is the main reason why rust is better, object ownership is secondary.
I just don't consider safer as better. it's such a reductionist view. c++ is better in every way except in explicit safety. People are gonna write horrible code thinking it's safe and efficient and it's most likely not. Enums are an example where the largest variant will dictate the allocated size per entry. It looks very elegant but it's the opposite of efficient. Rust is full of this and you need to know and be mindful about it or you'll write the most bloated inefficient programs ever. If rust picks up brace yourself for mountains of truly horrible code with a certified quality label.
@@indiesigi7807 How are enums the opposite of efficient? For that usecase, you WILL need to use the maximum variant size (unless you want to suffer with malloc). The direct translation to C/C++ has the same problem:
```rust
enum E {
A(i32, i32),
B(u64, u64)
}
```
```c
typedef enum {
E_A,
E_B,
} E_Type;
typedef struct {
E_Type type;
union {
struct { int a_first, a_second };
struct { uint64_t b_first, b_second; }
};
} E;
```
The main feature of Rust is the borrow checker.
C++ has unique_ptr and shared_ptr, which are analogous to owned value and Arc in Rust, but that's where C++ safety ends. In C++ invalid references are allowed, you can have multiple mutable references, can hold reference to a no longer existing value etc. C++ doesn't have any mechanism to avoid it. That's why things like use-after-free are so common in C++.
Rust does provide safety guarantees for references. All references are always valid, you can't have multiple mutable references, references can't outlive values. That's why it's practically impossible to produce memory-related bugs.
@@mk72v2oqVery Good explanation. I can see why rust ensure memory safety：only *One* immutable Reference is allowed for each Object/Functor. They will be destroyed when the ref counting reaches *Zero* (I.e. Ref to obj no longer in use).
@@indiesigi7807 Rust isn't only safer, it's tooling is way better, meta-programming way more powerful, it has better (and way easier) iterators, better functional programming support, traits, abstract data types, labeled loops, almost everything is an expression (and thus composable), native async support, etc., etc.
I have to find yet one(!) single thing that C++ does better than Rust!? I've been programming in C++ for over 20 years and just recently started using Rust: it's just way simpler, faster and easier to work with. It's not unusual that I can express the same algorithm with half the code in Rust.
"Ok, so hear me out on this: Rust" _mixed reaction from the crowd_
This is amazing but not the main reason why most people love Rust. Rust like used all the good practices that have been developed by the programming community and fit into a single language, almost each Rust feature could be a reason of its own to like it. The compiler errors are amazing. Rust Enums featuring algebraic type system, offering amazing error handling system with Result type. No null values with Option types, completely eliminating an entire field of problems. It isn't object oriented but still have interfaces (known as traits) and type methods, but no inheritance (which was like the part used badly in other OO languages). And I could just go on and on. Rust took all good parts from different languages, coding styles and paradigms, but removing the bad parts about em. Rust is arguably the best one yet, still not perfect and still improving.
And personally I found Rust as the best middle ground from "close to procedural" but still very expressive with functional programming paradigm.
I completely agree, rust is a language designed by experience
Main is a bit of a bad example because the OS is supposed to free the memory from your program anyway. Leaks are more of a constantly running program thing.
True ^
Sure but when you allocate in a hot function, you don't want your program to leak anyway
I'd like to add onto the garbage collector explanation that there are multiple types of garbage collection strategies, Java has a mark and sweep strategy, which marks memory accessible from the running program and sweeps the rest at regular intervals. Other languages like PHP use reference counting, where memory is reclaimed as soon as nothing points to it. They each have their advantages and disadvantages.
So doesn't Smart Pointers in C++ also solve this particular problem of memory leak when variables are going out of scope? Like if we have a pointer and enclose it in a class then if it goes out of scope it's destructor will be called which will initiate the cleanup code required to free up the memory. Is it not a good enough solution or am i missing something?
Not only smart pointers. std::vector is basically an array of variable length in heap that gets freed when out of scope. It is also used in std::string and in every class that frees up resources on its destructor. It's called RAII and it was a thing in c++ before Rust existed.
C++'s safety is an afterthought and is all opt in, while Rust's safety is inherent to the language and is all opt out. That makes a big difference and reduces what code you have to consider when something goes wrong. Also, if your rust program compiles, you can be pretty confident that it will work before you even run it.
@@mghinto I don't get this mindset though? Nobody is forcing you to use the unsafe c++. Nobody is also forcing you to not use the unsafe keyword in rust. C++ is plenty fine enough. RAII is enough.
@@starllama2149 The problem is that RAII in C++ is not mutually exclusive to the old ways of doing things. Modern C++ still allows you to freely allocate memory using malloc/new, modern C++ still allows you to get a raw pointer from a smart pointer, modern C++ still allows you to mutate a value through _any_ pointer pointing to a non-const value, smart or not. You may scoff and say something along the lines of "anybody who knows what they're doing wouldn't do this", and yes, you're right. The problem is not everybody knows what they're doing, and even those who know what they're doing can have a lapse in judgement and make a mistake somewhere that proliferates and leads to swaths of unsafe code. It's not enough to just trust that everybody and anybody knows what they're doing, which is what Rust understands and IMO gets right with its safe-by-default design.
It's a question of opt-in vs opt-out. In C++, you need to actively seek the safe pattern but doing magic with pointers is often easier and less verbose. In Rust, the ownership is enforced and you need to explicitly opt-out of it to be able to play around with memory freely.
Which one is a better option depends on your use-case.
When you say "Rust might be the best programming language", you blatantly ignore the functional ones
Good point, which functional language do you think would be in contention?
@jacobpradels For static verification, many dependently typed languages like Agda are well-suited.
All functional programming languages are of course memory-safe, but there are some which actually have comparable performance to procedural languages and do not necessarily use a garbage collector. I think Roc is one of them.
PS: Although my initial comment sounded a bit harsh, I enjoyed your video nonetheless, I was just taken a bit by surprise by your opener ^^
Nitpicking, but rust wouldn't pop arr from the stack after the move. It's the compiler that marks arr as no longer valid. It's a compile time check, not a runtime action.
C++ Smart pointers: I don't exist**
Neither does std::vector apparently
Generally well explained but left out are the MANY corollaries of Rust's philosophy such as standing on your head to get two objects that point to each other and the difficulties inherent in graphs. That you have to drag in special crates just to have a mutable global. New concepts entirely like lifetimes need to be understood, etc., etc.. I realize there are solutions to all this, but Rust requires a lot more out of the programmer than C++ does - it just does. I also realize that most Rust programmers would say that's a good thing and most of the time I'd be with them on that opinion, but to leave all this out will really not describe to a C++ programmer the difficulty of adjusting to Rust. This makes it seem like ownership is a no-brainer and "that's all there is" when, in fact, the devil's in the details.
Yes, Rust has a steeper learning curve than C++. On the other hand it's a lot less you need to learn to actually be competent. And Rust will let you know that you still have to learn while C++ will happily pretend like absolute garbage is fine. My favorite part of pretty much every C++ conference is when some speaker presents an innocent looking piece of code where even committee members in the audience can't tell why it's wrong.
isn't this just like an std::vector though?
Mastering C isn't just about writing syntactically correct code--it's about wielding an unparalleled command over memory management. True C programmers understand that the heart of the language lies in navigating the delicate intricacies of dynamic allocation, pointers, and memory deallocation. Efficient memory management is the core of performance, reliability, and scalability. Without it, you're merely scripting. To call oneself a C coder without this expertise is to misunderstand the true power of the language.
C programmers when assembly language wields a million times more command over memory
@@RenderingUser Assembly is like that old-school mercenary who gets the job done, but you've got to personally guide every bullet. C? It's the guy who follows orders but still might blow up half the team. Rust? Oh, Rust is that overly cautious rookie who's like, 'You sure you wanna fire that? You might hurt yourself.' Meanwhile, Assembly’s already smoking a cigar and counting the cash. Efficient, baby!
@@1n4f4bl3 Rust isnt the rookie. its more like the guy that has a 3000 page book of stratagies and wont let a plan go into action unless its detailed to perfection
@@RenderingUser Oh yeah, that language nobody used to care about. Now it's like the cool kid at the programming party, sipping its memory-safe latte while C and C++ sit in the corner reminiscing about the good ol' days when nobody cared if things blew up. Rust? Please. It’s like the hipster of languages -- 'I was safe before it was cool!'
@@1n4f4bl3 nice, casually erasing the contributions that Eiffel and Ada had on Rust. Like a true hipster would
2:10 When capitalism solves programming problems.
"Rust is good because..."
"Erhm achshually..."
It's the amps vs volts debate all over 💀
Great video btw actually made me so curious that i would like to learn more about rust
Surely it is because I’m an old fashioned C/C++ programmer and I can’t still see the beauty of this ownership paradigm, but right now I can only think about how annoyingly painful would be for me to try coding about anything in Rust, I already have a headache just from thinking about it.
I can definitely see the advantages of of the compile time analysis and strict memory management Rust provides, but I’m afraid it comes with a cost in flexibility and usability that may be too high for certain situations.
I have a headache thinking of the uncertainty from languages that don't have a borrow checker. On rust I hardly even have to run the program. If it compiles, it works.
exact opposite for me
i love borrow checker and just thinking about raw pointers gives me a headache
its all a matter of what youre used to, really
yeah, with c and c++ you get to focus on the problem rather than the borrow checker
@@pyyrr you only focus on the borrow checker because you keep actively fighting against it. Learning to code involves learning the best design patters for a language too.
@@RenderingUser i dont fight against it. i just use c++, that solves the problem.
Java would NOT leave array on the heap in these examples.
See "escape analysis".
Java would work the same way as Rust. Of course, in compicated cases, array reference may eventually escape few scopes away and be left on the heap, but we can find equivalent example for Rust when this happens too.
best visualization of memory i've seen
Unfortunately I’m stuck modifying a C++ codebase, it’s a shame because I’d love to use Rust but I don’t have the time to rewrite this entire framework in Rust 😂
Amem brother. Tell these guys why most ML, LLM and AI codebases are C++ rather than rust
C++ works exactly as described in the video 😂
Shared pointers have a slightly higher runtime cost than the ownership model since a counter has to be incremented / decremented with every call. The upside is that shared pointers and weak pointers are wayyyy less restrictive.
@@Biriadan can you clarify what do you mean by restrictive? also the last part he explained sounds just like unique_ptr and std::move to me. well I guess not if its owned by multiple at the same time.
@@zanagi I can have multiple pointers to the same block of memory and be able to mutate it from any of them without any special constructs needed at all.
I think to get the same write many behavior you need to use special constructs in rust like rc and arc.
Powerful and well designed language 🦀
Thank you for the great video!! what software do you use to make such illustrations?
Nice video, I'd like to share how this 2:53 is similar to how C#'s span works, the span is automatically freed when it exits the scope.
{
var array = new int[10].AsSpan();
} // The array is dead now, no heap allocations, no GC. 🚀
You could also just allocate on the stack (via stackalloc), but that is not a good idea for bigger arrays.
It can’t be the best unless it does all that, but was simple. Instead it’s complex with a steep learning curve. That’s not a small issue, people don’t run companies don’t understand the value of being able to move quickly.
Wait... but c++ does pretty much the same things. Only difference is = copies by default and you have to explicitly std::move
Which is precisely the issue. Sane defaults need to exist
Copies by default only if copy constructor or copy assignment is defined for the object, otherwise it is a forbidden operation
@@NEWDIABLO96 I mean most of the time those operators are defined by default.
I believe it's only not defined if a custom destructor is defined.
first, they told me to respect ring zero.
then they told me to respect women.
now they tell me to respect memory.
but there was no one left to respect me
Hipsters performing mental gymnastics to not use valgrind smh
fr, valgrind is the cure
what software do you use to animate this? i would like to know
Microsoft Powerpoint haha
I know its off topic, but your animations are really smooth. I especially liked the transition between blocks of code. How did you make those?
In C++20 there is ownership with smart pointers
I'm building a programming language dose dose reference counting at the compilation level
public and static -- exposed one immutable the other not ,
local -- stack and private
I maintain memory buy counting references during compilation when references hit 0 it's unallocated (done right after the last reference is nulled )
it dose have self-referenece issues of which the complier will have to figure out
A better solution is to combine rust's approach with reference counting.
This concept is called RAII and you could do it in C++ years before Rust existed
yes, infact Rust borrowed it from C++ but the fact that Rust has it as a 'default' mechanism it what is better (and safer) IMO.
right, but you might forget to handle this in C++ unlike Rust it's done automatically
all of your points are skill issues at best
@@sot_dev RAII is automatic in C++ though. That's the whole point, you don't have to think about it. If your class has a smart pointer, or other object with RAII, the class will have it's destructor automatically generated. The only time you need to write destructors yourself is when wrapping C code, just like Rust.
@@BoardGameMaker4108 ah nice! thanks for the upd
I prefere c cause any type has the freedom of being entirely allocated on the stack, static heap or dynamic heap.
I also like treating bools like ints and inlining my logic into jump tables using 2d matrix of of function pointers so false false is [0, 0] true false [1, 0] or true + true and false + true is [2, 1]
I think rust is great for low level embedded applications but not for drivers and systems programming.
So I'm not getting something, why not just make arr2 point to arr, and since arr is being pointed to it doesn't go out of scope until arr2 does too?
becuase in rust a block of memory has one owner.
if you want that same block of memory to have two owners, or shared ownership you can use rc or arc (for multithreaded)
it gets even weirder because this type of owner ship gives you a read only access type.
if you need to be mutable as well you need to use refcell,
and when using arc (for multithreaded) you usually would use a mutex, theres rwlock which i never used so idk about it
theres probably alot more.
Why in Java, when "arr" is popped out of the stack, does the system not automatcally frees the memory referenced by "arr" in the heap?
Oh... I get It now
But the system could store a value in the heap along with the allocated data to store the number of references to that address and every time the ownership is duplicated the number increases, every time a reference is released, the number decreases and when the last reference is released with the value equal to 1, the heap data would be deallocated once and for all. What would be the consequences of implementing this and what problems that a gc would solve that It can not solve?
Oh, there is a name for It: "reference counting". GPT helped me with that
Idea is good. If only they could adopt Java syntax to make it more programmer friendly it would be perfect.
i dont get it. unique_ptr also can have std::move so whats different?.
Very clear and understanding .. you must do more videos like this
I mean, I like Rust, but sometimes I don't need these restrictions in my way. I would prefer the freedom of C. Besides, there are analyser tools that can help locate potential memory leaks.
The beauty of C is that one can imagine what the assembly code would look like behind the scenes, with Rust's abstractions it would be more difficult. You pay with overcomplexity for just not having to free memory yourself.
All you have to do is use tools that help you locate problems in the code where memory leaks could be, OR design your C code that way so you don't have memory leaks (so that you know for sure where all allocations and deallocations are). With Rust you would still have to design your code to comply with borrow checker anyway.
Rust could be a language for perfectionists, but you can still be one using other languages.
based C freedom enjoyer
"All you have to do is use tools that help you locate problems" so..... a language built in tool like a borrow checker
@@Jardynq when you develop in C, the main "borrow checker" should be in your brain. Good architecture and code design will solve these problems at early stage of development, and perhaps even save you from using tools for too long (depends on the project scale). Rust forced slightly different way of coding becuase of the language design, and this could create a new set of logical problems that you would still need to address.
Take Linked List implementation in Rust for example. I don't need this protection that Rust forces, I need full control.
I guess Rust is really needed in those cases where programmers can't protect themselves from making mistakes.
I really don't like the idea of such fundamental restrictions that force me to write code in some other way, not the way I want it to be written. No language will take away my freedom. Rust can be still used for critical parts when and if I choose it as a tool for the task. But becoming pure Rust evangelist is not going to happen.
You have control in Rust too. You clearly don't know anything about Rust. You just need to opt out of safety.
C is better at absolutely nothing. Rust can do all the same things, while preventing you from making mistakes.
Where can you learn this kind of topic? I feel like, i'm still missing a lot of information that i should've know. I want to understand more the java lang. Where should i start?
@@cluelessProgrammer1 google or talk to ChatGPT. “How does Java handle memory management?” Then compare it to other languages.
Likely the answer you get will prompt more questions
“What is a stack?”
“What is a heap?”
“How is memory allocated on a stack vs heap?”
If you just ask a few questions then ask about the things you don’t understand you can learn a ton
So the tl;dr is Rust generates the free() so you don't have to
Is this the same concept as C++ smart pointers?
Where is C++ comparison?
how does this apply when using async though?
dude your voice is that on purpose
@@Joe3D no
Now, I’m probably missing something, but why not just… share ownership? When an owner is removed from the stack, it or an intermediary just double checks there are no other owners before unallocating it. Yes, this requires storage to know the other owners, and possibly an intermediary process, but given you could using something like a hash table to store this minimal data compactly and quickly accessible, and the intermediary process (if it exists) would only be executed when needed, instead of constantly.
Would this not minimally impact the efficiency of the concept, but remove all the drawbacks of switching ownership and multi-scoped variables? At least to me, this functionality concept of this seems to fundamentally break scope inherited variables in closures, which sounds terribly annoying.
This would be referenced counting instead of ownership.
Rust also has that with `Rc` but it does use a lot more memory and may even be really dangerous when doing multi threading when releasing both Rcs
thats what Arc is for, a thread safe version of Rc with essentially a mutex to change the inner rc.
correct me if i'm wrong.
Great question! I really appreciate questions like this and I think it highlights something I forgot to mention in the video which is that one of the big benefits rust provides here is the ability to do this checking at compile time rather than runtime. And this allows for catching various kinds of bugs before code can even be built.
The solution you mentioned sounds very similar to reference counting.
I’m far from an expert in language design, but there are trade offs when you move in either direction.
That exists in Rust too.
Thanks for the informative answers!
I’m not entirely sure why that wouldn’t be the default, but there probably is a good reason.
I’ve been meaning to learn rust, if nothing else learning about this more might be a good reason to startx
You can share immutable refenece easily in Rust, also you can "borrow" someting for a moment, all static at compile time.
If you need runtime safe sharing there also many ways but the are explicit in Rust, explicit in function and additional cost.
Rust’s strict ownership rules can sometimes lead to inefficient patterns when compared to languages like C, where manual memory management allows for more granular control. For example, Rust may require clones in certain situations to satisfy the borrow checker, which can lead to performance overhead.
If you really need a raw pointer, unsafe rust exists. the difference is, you can limit the unsafe code to very reduced sections, and make the api safe externally.
Incorrect. You can do the same thing in Rust, it's just more explicit.
I too pray to the god of safety. Even people with the best intentions run into the sea, that's whyI wear a life vest. Only thing I refuse is to debug. Not part of programming for me and I hope I never encounter such a situation.
Before posting such a ridiculous claim, you should have checked the RAII. This makes your Rust so cool, to destroy something when goes out of scope. C++ smoked this long time ago.
Rust has better implicit move semantics management in compiler. But RAII is C++
Rust did not introduce the concept of ownership. It's just the first performance based compiled language to come out in a long time that *also* facilitates ownership. And what... do you think you get this all for free? What you're sacrificing is the overall design and maintainability of your program since you become burdened by its approach to ownership rather than being able to implement your own.
Incorrect, there's no burden at all. It makes it a lot easier. You should learn more about Rust before you judge it
@@antifa_communist "Someone has a position I disagree with so it must come from a position of ignorance". I'm not even surprised someone who bears the name "antifa_communist" thinks like this. Grow up.
what is stopping java from implementing this?
Backwards compatibility i guess
Awesome, thanks
Why does your voice sound like it's constantly dying?
Wow so rust reinvented unique ptr waow 😊
Actually, you picked a really poor example at the start.
The issue is not with programs that just forget to clean up resources and then exit. The kernel keeps track of heap allocations and once the program terminates it just frees that memory right up. This is technically a memory leak, but it has no effect on a modern operating system. While this is not best practice, this is perfectly safe and fine to do.
What you should have gone with are applications like Kernel Modules or Daemons that continually run in the background but never use free() to give back memory. Those are a much bigger problem as they constantly call for more and more resources, but never free them. This will, over a long enough period, cause an _actual_ memory leak.
And to be completely honest: Rust fanboys WAY over-hype memory leaks. Worst case the Kernel denies the resources and you get an error which crashes the program and frees everything anyway. Rust fanboys really need to stop acting as if memory leaks are a thing that every application needs to care about. In 95% of applications you won't even notice that they occur. Yes, those 5% of applications benefit from it, but that is no reason to rewrite all of the programs in Rust.
you kinda sound like chris griffin
Rustroon
This all works fine with hello world example. Good luck with implementing something real in Rust
true. i still havent seen it actually being used in a real project
Real things are implemented in Rust. Microsoft, Google and Amazon use it. It's in Android and Linux.
@@pyyrr are Linux and Android not real projects?
@@antifa_communist I am not saying Rust is not used anywhere. I am saying when you try to use it on real project it becomes a lot more challenging to write Rust code.
Even though the companies you mentioned use Rust, its part must be about 0.001% of all their code.
0:35 of a video and already i can say skill issue
@@mppl_yt502 nice
Zig >>>>>>>>>>
What Zig ? It is amazing C replacement, but different beast :)
ah yes, the assignment operator actually _moves_ things! what a well designed language.
You don't understand what that means at all. Nothing is actually moved. Ownership is moved. Please learn before you make assumptions.
@@antifa_communist perhaps you should think before you start saying even dumber things.
obviously nothing is "moved," ownership is just changed in memory. The problem is that the values you would normally get from the original variable are no longer accessible from that variable, and instead appear to "move" to another variable.
i.e. the psuedocode "a = [0, 1, 2]; b = a;" would "move" ownership of the array from a to b, resulting in a having no value.
You should claim rust is the best if you can compare it with something like Zig, I believe zig has the best of the two worlds
Watch Primeagen videos..he often mentions Zig got 80% of Rust memory safety features, but is 80% easier to write compared to Rust.
Zig is still incomplete
No. Better than C++ but Rust is still better
Rust Probaganda be like C is Old C++ is Bla bla bla and in the last minute they start talk about Rust and then the vedio end
I don't really get the obsession with Rust's ownership model, yes its cool and almost always promises the programmer to handle memory deallocation in the end of the scope, but... combined complexity of other things in the language like enums that can hold values , Heap based types (Rc, Box,Arc,etc.) or Macros make it unbearable to quickly develop things. Problem that nearly everyone point at, of: "bug because of use after free" or "forgot to free() in C, unsafe!!!!" aren't as much of a deal as the unnecessary complexity of doing literally anything in the language.
It could've be the case, if there where no debug tools, valrgrind or bounds checking in all of the system programming languages for decades. I doubt that you need majority of the features (even core one) in rust to make "safe software".
what is ti with rust programmers i've never seen similar weird community of a programming language, i've used rust for 2 years along side C/python and Go recently, it is :
a simple language + "best practices" enforced by the language
anyone can by choice implement those concepts in any other language .
for example
all languages have mutex, rust enforces mutex wrappers on mutables to avoid lock-ins (you forget to unlock) the same wrapper could be implemented in any language in 10 lines of code only rust ENFORCES IT ON YOU and calls it a feature,
get over yourself just learn the concepts and use any language you feel productive using (5% performance increase doesn't matter in 99.99% of your projects)
by the way none of rust "best practices" are invented by rust team all are known techniques from 70's and 80's long before they were even born
"none of these things was invented by rust"
Funny how you'd say that when rust is unlike most other popular languages. Sure it existed somewhere in random languages. Rust put it all together and streamlined it.
someone pls explain to him Rust does not protect from memory leaks in the first place..
It actually does. What you mean, I believe, is that it cannot prevent you from deliberately causing a leak (and obviously! given that it includes mem::leak()). But it definitely prevents inadvertent leaks in almost all cases by tracking ownership and dropping where required. That's what is meant, not that it's literally impossible to cause a leak.
@@peter9477 Reference cycles with reference counted pointers can produce memory leaks and many times its not trivial when those will happen.
@@marcossidoruk8033 How are you going to make those in Rust without using unsafe code?
It protects you from certain classes of memory leaks. Of course you can still use a Vec or HashMap improperly and have memory bloat, but those are more of logic problems than random footguns. It's not perfect and it was never meant to be.
Lol haters saying that rust can leak memory without examples as always 😂
Garbage collection is hard, so Rust pushes memory management issues onto the programmer. While this speeds up execution time, it slows up development time. I would rather devote my mental energies to the problem domain than concern myself with the complexities of memory management.
Development time is slowed down due to uncertainties that require extra runtime bug fixing. In rust, if it compiles, it works. If you don't want to deal with the complexities of memory management, don't use a compiled language
@@RenderingUser Golang seems to be a good compromise between compiled and interpreted languages.
the fact people still need to sell this language to get people to use it instead of just using it 😆 what a joke
People do use it though. What do you mean.
too much vocal fry
C better lol
Rust hasn't invented anything, that's already in C++ with smart pointers
3 words before the end of every sentence you run out of breath, can you please talk normally? it is disturbing
With garbage collection, every object has ownership, hence better.
i love your videos but your voice is annoying
@@playthatsoloboi3705 you get it
It is a big claim, going forward seems like python will be the best programming language
me waiting for my empty python for loop to finish (its on the 2nd iteration and its been 8 hours)
Rust is a joke!
You are a joke
why???
No memory management isn't hard. Free the space. Why do you need some fascist language to enforce what decent programmers ought to be doing. Also, memory leaks may or may not be an issue in a program. It is inefficient and not good practice but depending upon the task it may or may not be an issue. Trading simplicity for complexity is not always the best solution.
There are many reasons why you might not free the space. You might forget for example. You don't understand Rust at all. Comparing it with fascism is laughable.
clickbait
Rust re-invents RAII. Wow. So cool. No.