9:19 I would say exactly the opposite, in this situation the best for your program is to crash, the worst is to get garbage and continue as if nothing had happened as it might takes months, years or decades to find out such a problem (especially when dealing with processing data and not knowing the kind of output you should expect). What usually happens, though, is that you get intermittent crashes depending on the memory values you get from that dangling pointer. Pretty sure the constructor and destructor in the C++ version needs to have the same name as the class, but that's besides the point of the video.
I was gonna write that. The best case for a UAF is usually a crash, rather than silent data corruption, or revealing random memory. Both of them are security/safety risks, which can undermine everything your program does.
Yep. When things break loudly, it's a big motivation to go fix it. You can also log exactly where the crash happened and the state to track what caused it so you can prevent the problem in the future.
Depends on the program, where exactly in the program this problem appears, and how often it does so. For example if the value was storing the color information for a single pixel, and that value is garbage once every 10 million outputs, and all the program does is display images on the screen, I'd rather have that single pixel flicker with random colors once every 5 frames than have the program crash. At least as a user.
@@256shadesofgrey This thinking is what leads to scanners giving you wrong numbers in your tax reports, look up "Xerox randomly changes numbers". The program should crash and make the developer fix it immediately, not try to ignore it forever.
@@256shadesofgrey Hehe, fun fact about Undefined Behavior - you just can't assume what would happen when it is triggered. As an example: you program might run on the same amazon cloud server as some Radionuclide therapy-software, and UB in your code might trigger some unknown exploit that breaks vm isolation and corrupts command list for RNT device.
5:50 in C++ you need to tell the compiler if what you're deleting is an array with delete[] instead of delete. In that example the memory won't have been freed properly.
@@LuizDahoraavida now you're getting it :) this is why rust was created in the first place: to eliminated a whole class of bugs caused by common and easy to make mistakes
This kind of sloppiness does a real disservice to the channel and the intent of the video. You can't be bothered to COMPILE all your examples? Or at least "*" annotate the errors in the video? Such obvious errors are a disappointing distraction that pollutes the message.
It seems a little apples-to-oranges to have a raw pointer in C++, but have a vector in Rust. Both of the languages have a suitable vector type that uses low-level operations under the hood and packages that up into a nice-to-use type with the hard work done for you. Using the video's examples for the two languages makes it easy for people who aren't familiar with them to walk away with a very incorrect view of C++ that remains pervasive in the field, but doesn't reflect how ordinary code is written at all. The Rust comparison should come in at the point where it starts to offer more guarantees and functionality than what C++ can offer, and point out that it's part of the language rather than static analysis. Even moving (which C++ has too, just different) isn't so much about one owner for something like a vector (the vector already represents a single owner of its memory) as it is about not needlessly copying the vector. Either way works, but one makes copies explicit. There are other contexts where it's more about a single owner for a resource. Borrow checking and trying to use something after it's been moved from are where Rust really starts to bring more to the table in this regard than static analysis with accompanying rules on how to write code so the analyzer can reasonably work with it.
This is the same problem I have with most Rust vs C++ comparisons -- you get someone who appears to have virtually no knowledge of C++ that isn't at least two if not three decades out of date confidently saying why their insanely contrived example that no real person would ever do could be better in Rust. I strongly suspect there are things that _would_ be nicer for me in Rust, but instead I just keep seeing crappy Rust salespeople that don't know any C++ but try to pretend that they do. This person doesn't even seem to know how the very basic fundamentals like how constructors and new/delete works (this feels too extreme to be live-demonstration nerves, and insane they didn't doctor it in post), so I'm very doubtful they ever knew anything about C++ at all. From what I understand, most of what Rust brings to the table is advanced static analysis, which is great, but C++ has a decent amount of that too (e.g. use-after-move or use-after-free).
Yeah, happens a lot. I find a lot of Rust programmers are super into it, espousing all of it's pros, why everyone should use it and usually comparing it to C++. There's also an element of functional vs object-oriented where they all espouse functional or functional-style programming to be *always* superior to OOP despite the fact that OOP is still one of the most common programming paradigms in the world. They all seem to be drinking for the same fountain that says "this is why Rust is better than C++", but don't actually know anything about C++ beyond the base language and usually the 98 standard. Rust is kind of a cult and those who love it think every other language is terrible, especially C++. Personally, I love Python and C++, but I'll use whatever suits the task best.
@@claytorpedothe advantage of rust isn't that it *offers* static analysis, it's that it *forces* static analysis by default. Someone who knows very little C++ is very likely to make this sort of mistake without knowing how it could've been prevented. Someone who knows very little Rust won't make this mistake because the compiler defaults don't allow for it.
The video is not demonstrating the Best Practices of both languages and how THEY differ. It is demonstrating the MINIMUMS of the language and how they differ. You can constrain C++ to get much of the same benefits as rust, with the added boilerplate, static analysis configurations, and code-style enforcement that comes with that. Even with all those things, it is still POSSIBLE to create these kinds of bugs because the language allows these unsafe operations BY DEFAULT and won't warn or flag that you are doing something that may cause issues. In rust, if you wish to do these types of operations for the few valid use-cases where they are unavoidable, you HAVE to tag that block as unsafe. In the event of a crash, that is going to be the FIRST place you look.
I was wondering about that... I was thinking "surly they would have caught that, maybe it is a new feature in C++, the constructor can just be called Foo"
Even though the goal here was to demonstrate Rust RAII mechanism, it's worth mentioning that modern C++ provides equivalent concepts using unique_ptr and moves. Nowadays, you rarely need to delete memory manually in C++.
You can still get dangling references pretty easily. Rust solves this with lifetime analysis. This can often be picked up in c++ through static analysis but Rust guarantees that dangling references won’t compile. The c++ is very poorly constructed - just accessing the data() function of std::vector would have been a better example to construct a dangling reference.
This video conflates RAII and ownership semantics quite a bit. This is a common misconception but if this is meant to be an introduction to either concept, this will most definitely confuse a newcomer to these concepts. You can explain Ownership Semantics without ever referring to RAII whatsoever and vice versa. Ownership semantics can be used to aid with a few issues that RAII in C++ causes (such as over use of copy constructors) but they solve different orthogonal problems entirely. C++11 onwards also has all of these ownership semantics (rvalue references, std::move, std::forward, etc), but they are an opt-in thing rather than something that is required like in Rust. Also, if you are wanting to reduce resource usage as much as possible, RAII is not the right tool for you and will most likely cause you to waste more memory than other approaches.
I'm not sure I agree at all. This video isn't confusing RAII and ownership semantics at all, but is illustrating how RAII must be handled and enforced for it to work properly. To allow RAII to work at all, the borrow checker/ownership semantics have to be enforced. How is this conflating RAII and ownership semantics? I'm also unsure how RAII is "wasting memory" to be honest. Rust automatically drops things that go out of scope, but you can also drop things at any point.
@@noahhounshel104 @kwanarchive @Zsombor Hollay RAII on its own does not necessarily waste memory compared to other approaches, however the general culture assumes RAII means you should allocate singular things instead of thinking about your allocation separately from your single objects. As a result, a lot of memory is wasted because you off-load the allocation aspect to the single object, whereas RAII could still be useful if you did not do this. Another issue with C++ specifically is that they conflate construction/destruction with allocation/deallocation. It is extremely useful to want to allocate an object and then construct it at a later time, destruct it and then deallocate it at a later date, but due to the way C++ has been designed and the culture around C++, most people couple them together (making things bad). Constructors and destructors also do not "return a value" meaning that the only way you can signal something may have gone wrong is by throwing an exception (which might be a huge issue depending on the problem space). This is why many people will just use explicit `init` and `destroy` functions/methods instead of relying on the ctors/dtors, thus bypassing many of the features of RAII. I can give you loads of real world examples of codebases that use RAII heavily that are extremely wasteful of memory (compared to other approaches). And to clarify, RAII is not inherently wasteful but the culture around it and how it the languages that have tend to be designed nudge you to use it in such a way that is extremely uncaring about memory allocations by making them hidden.
@@GingerGames Eeehhhh. I suppose you can view RAII as "wasteful" if you are never deferring the creation of the objects to a later date, but in the Rust world doing so would just be an Option which is useful/important for a whole host of reasons besides having deferred allocation.
The reason you can't borrow mutably and immutably at the same time isn't because one function is expecting the data to be unchanging while another is expecting it to be mutable. If that was the case, as you are presenting, multiple mutable references would be allowed at the same time, when they very much aren't. Mutable references are meant to be exclusive so there's only ever one point of mutation for a given piece of data (and no immutable references at the same time), which is done in order to avoid data races and the such. This is why mutable references are often called exclusive references and immutable references are often called shared references. This principle is also applicable to `Rc`, which was mentioned. Rc basically gives shared references to the data, but it cannot be mutable; to have shared mutable data, one would have to use one of the interior mutability data structures (in the case of an `Rc`, you'd probably want a `RefCell`). I think it's important to make this clear when introducing the topic of references in Rust, because one of the core design principles is "fearless concurrency", and as such that is baked into its fundamental ownership principles. That is to say, these concepts are inherently tied in Rust. I don't know if this was an intentional simplification, but it's something that shouldn't've been omitted imo. As an aside, `Rc` and `Arc` aren't really like garbage collection. Like, they can be used like garbage collection, but basically instead of having a garbage collector go through the memory and seeing what should be dropped, `Rc` and `Arc` keep an internal counter and then increment it when cloned and decrement it when dropped. When an `Rc`/`Arc` is dropped and there's no more references, it just drops the underlying data. This means that using these smart pointers has a slightly different cost to the equivalent code in a garbage collected language. (Though this isn't really a major point.)
also having multiple mutable references might cause data to become invalid. imagine taking a eference to the first item in a vector, and then overtiting the vector with an empty one. now our reference points to unitialized memory
Basically you pretended to "fix" something the video doesn't say in the first place, and failed to do so. I am used to this pointless pedantry on StackOverflow: not ready to face it here on YT, frankly.
@@valcron-1000 I think the term GC is often misused that way, but I don't think it's correct. Python, for example, has a garbage collector, but it also has ref counts, and the GC is only there to clean up things the ref counting can't handle fully (like cycles). You can't have garbage collection without a garbage collector, and Rust definitely doesn't have one (any more).
I've not coded in C/C++ for a long time and I was having an aneurism when I saw that and wasn't sure if the code was wrong or my memory. Thanks for the comment letting me know I was right!
If this was the only error in this video. Most variable and parameters names were wrong in the Rust example (n becoming bob, b, becoming bob, etc.). I liked the video but it was a mess. Trying to compile the code to show what it does would have allowed to detect those problems.
@@Hexalyse That is the issue with academic CS though. They are more interested in concepts and less in being code monkeys. They can design the most complex ideas and constructions, but in the end the people that work with the language on a daily basis will know a language better than they do.
@@Hexalyse It seems to me like all, or nearly all of these errors would have been caught if he just tried to compile his code after each demonstration. And actually *demonstrate.* But to be fair, he seemed a bit nervous in front of the camera and I don't blame him for getting lost. Next video will be better, I'm sure of it :)
@@Hexalyse Explaining and coding at the same time is not the best option for everyone I guess! 😆😁 Probably it would have been a better idea to first write and test all code first before showing it in a presentation. Explanation was fine though.
Some of the things Rust does the right way: 1. RAII or memory ownership model - follow few rules and forget about memory leaks 2. Traits composition instead of trait inheritance. 3. Powerful enums/unions - can hold values. You have to consider all cases 4. Pattern matching 5. No NULL. Instead - enum with optional value 6. Powerful macros My main complaint with rust is that compiler won't let me be silly and write bad code. This also means it won't let you shoot yourself in the foot. But the learning curve is a bit steep. Rust is so different from other languages
Rust is inconvenient to prototype things in. That's probably why we see a lot of Rust rewrites of existing programs, that already got prototyped decades ago.
@@ifcoltransg2 for some stuff. though, i actually find myself specifically leaning to rust to prototype in, because the way one lays state out makes it a lot easier to understand how the program would work, for me
@@0x5DA I did overgeneralise. I guess Rust's type system is great when you want to make sure things end up correct and well structured. It gives you some support there to create a solid foundation. But I do find, for the kind of project you just want to get working, it's easiest to throw up some Python onto the screen first, rewrite it in a type system after.
@@ifcoltransg2 After using rust for personal projects and then nearly a year in production, I now find it much easier to prototype complex ideas in. The biggest help it provides is in easily helping you design your data model in a way that your program can never reach an invalid state (mostly thanks to the absence of null or similar and the conciseness of enum variants). Nowadays when prototyping something I usually go to Rust first because I know that if there's a lib to do what I want it'll 9 times out of 10 (if not more) have standardized, easy to navigate documentation and the auto-completions brought about by the strict type system will guide me through the process. I do agree with the OP on that it takes quite a bit of time to learn and even more to become actually proficient in it (not even mastering it, just being able to "realistically" pick Rust for a time-sensitive project); I wouldn't ever recommend it to someone as a first programming language.
@MenaceInc While you’re correct, C++‘s type inference, which is similar to Java’s, C#’s, etc. isn’t _quite_ as powerful as Rust’s, which is more like those found in functional-first languages. For example, in C++, you can’t write something like “auto x;”, while “let x;” is valid in Rust (provided the type of x actually can be uniquely inferred by how it’s used).
If you have rust-analyzer installed you also get phantom type hints inline with your code which makes it so nice to read. No need to hover over variables to see the type like other languages. This seems small but it's so nice.
@@konga8165 Many of the popular languages's LSPs have that kind of functionality though..? It's just returning more information to the editor following the LSP standard.
Thank you for this explanation of RAII, it was really interesting. But nearly all examples shown wouldn't run as either variables or methods are wrongly named. (Foo constructor in Bob, bob instead of b in all rust functions)
I think this was explained quite poorly. You can write as much garbage code in any language you want, including rust. What matters is that when you try to compile the code, the rust compiler rejects much more (memory related) garbage than the c/c++ compiler does. Whereas c/c++ will allow you to get to runtime and may or may not crash then, rust doesn't allow you to get to runtime at all until you have fixed these issues. And not once you showed any compiler output at all. Which is also probably why you kept using variables that don't exist at all.
I work as frontend and I've started using Rust because I was missing messing around a low-level language. I'm in love! It's harder than JS (and way slower to build anything) but the borrow checker and the compiler are so so so good.
21:01 You also can't have a mutable reference to an immutable variable, which Ian had at this point. And regarding mutable and immutable references, it's not just that you can't have both of those, you can't have _any_ other references, mutable or immutable, if one of them is mutable, for similar reasons. (It's a little more subtle, though. For these purposes, Rust only cares about the span of execution when the variable is actually used. That's why the example with moving an object from one variable to another is fine, because after that the first variable isn't used. In the same way, you can declare and use multiple mutable references to the same object in the same scope, as long as the regions where they're used don't overlap.)
Great video. One remark would be to try compiling your examples next time. I think people unused to these languages could become confused when the code isn't accurate.
Nice video, the Rust borrow checker is pretty cool, but the C++ comparison didn't make much sense. C++ has had smart pointers for 12 years now (maybe more with boost), which get rid of all the problems except dangling references. You never write new and delete in C++, you never use raw pointers that own memory, you can move or only "borrow". The only thing where standard C++ will not help you is if you borrow a pointer and try to access it after the owning pointer deleted the memory (so dangling references).
Smart pointer still sucks though. Not everyone will use it, and adds complexity. Atleast Rust understands what you're doing and prevent errors before you spend hours debugging.
ปีที่แล้ว +1
There are a few more things C++ won't help you with but yeah, this was kinda strawman argument.
@@hanifarroisimukhlis5989 Not true. Smart pointers are excellent. On the other hand, the time you save on debugging with Rust, you waste fighting the borrow checker.
Your constructor and destructor for class Bob should be Bob and ~Bob, and not Foo and ~Foo. If you allocate an array with new, you need to use delete[] to clean that up, not just delete. In your rust code, you refer to bob when you variables are named n and b. Maybe you should get an IDE that highlights errors for you. Vim is great and all, just use syntastic or some other plugin to do that for you. Bare pointers are fine so long as it's simple and easy and there is no chance of accessing memory after it has been freed or it being very unlikely that you forget something. You should just use smart pointers instead otherwise. Unfortunately something that starts out simple can quickly grow in complexity and if you are not careful designing your API to your bob instances, someone might pull a pointer and use it outside some scope. Instead of trying to remember to allocate and clean up in two different spaces, you should just let the smart pointers handle that for you. They are well optimized. They do of course have their own drawbacks like cyclic dependencies that need to be watched out for, but generally they are the better choice. In your Bob example, a unique pointer would simply not work as you can't copy it without handing over ownership, and a shared pointer would work just fine, although you still wouldn't want to just return it like that as n probably makes no sense without bob. A weak pointer is probably the right choice here. If you want a fair comparison, then bob in c++ would also hold onto a high level structure, like std::vector, instead of a bare int[].
Err, no, an array of int would be represented by int*. int *x = new int; // fine int *y = new int[5]; // also fine delete x; // correct delete for single item delete [] y; // correct delete for array int ** would be an array of array of ints or a way to pass an array by reference in a C-style function so that you could (re)allocate it. But you are right about the rest, std::vector is almost always preferred if you need a dynamic array, or std::array if you don't.
6:32. RAII doesn't put allocation/deallocation as work on the programmer. The programmer can use STL containers and pretty much never use the keyword new. It is called rule of 0 and is the core essence of modern C++.
This is a very thorough explanation... thank you for that... But I must point out that at 5:45 inside the cpp program, within the destructor, the use of the delete keyword (delete this->n) in order to deallocate the array is wrong since it only removes the first element as the array is technically a pointer, therefore you would have to use the delete[] keyword (delete[] this->n) or loop through and delete each element. Thank you for this wonderful video ❤
So long as a mistake can be made, it will be made eventually. To me that's one of the greatest strengths of Rust. It prevents you from making common mistakes by being opinionated enough in it's design.
What wasn't mentioned is that the C++'s standard library is build around RAII and the notion of moving data around, so the concept is not new for Rust. Rust just enforces it by the compiler, while C++ lets you use RAII as well as unsafe resource management.
You absolutely wrong when tell about C++. C++ already has RAII classes in STL, and in most cases you do no need to handcraft memory management. Also, resources are not only the memory, as other commentators mentioned, it might be any thing what you get from OS, like: window handles etc. The key difference in C++ and Rust is move by default in rust, and borrowing.
Immutability works much differently in Rust than in TS. In TS, when dealing with non-scalar values such as objects or arrays, a const won't allow the value itself to change (e.g. memory address), but you can still push to an array or add a property to an object. In Rust, it's an effective Object.freeze by default where you still need to declare "mut" to allow modifications to the underlying compound value. This is a very important distinction.
Lack of mut in Rust is much closer to const in another language... C++. When applied directly to an object (like a variable), the meaning is basically the same in both languages (but there is a significant difference when applied to the type of a reference). Whether for the presenter's lack of C++ expertise or another reason, this video makes it look like the difference between C++ and Rust is many times greater than it actually is.
So, in the C++ sample you use raw pointers and manual memory management, which is not recommend in modern C++, and you could use std::vector and return it by copy, move or const reference then you'll get the same behavior as in Rust or whatever you can want 🤷 And don't forget about references in C++ too. However, I agree that more control that C++ gives to developer requires a lot more responsibility.
The C++ code is wrong in the video. First off, the constructor name. And also, in C++ if you allocate an array you gotta use delete []. The concepts were explained somewhat vaguely. I recommend anyone trying to learn this, trying to the same stuff you do in C++ just write in Rust, and the compiler will automatically guide you towards the right way to do things. In C++, it will just let you do that stuff, no problem.
The "many read-only or one read/write reference" rule is also part of the dangling pointer protection. Imagine you have a Vector with a bunch of elements, and you take a reference to one of those elements. Suppose you were to now extend the vector. In that case, you might exceed the allocated capacity, causing the whole thing to be moved to another place in memory -> your reference to the original vec (which has now been deallocated) is now invalid. Besides that, not allowing two mutable references also prevents data races, which are considered unsound in rust. It might also be worth mentioning that memory leaks are not considered unsafe or unsound in rust and are totally possible with safe rust(Box::leak, or having reference counted smart pointers point to each other in a loop like Rc1 -> Rc2 -> Rc1).
The vector case you mention is critical. I’ve had bugs in a C++ program just due to passing a reference to an element on the stack along with a reference to the object containing the vector. Way farther up the callstack that vector grew and the reference on the stack got silently invalidated. Because of how complex the code had grown, going back and refactoring to eliminate this ‘unsafe borrowing’ was completely impractical, and the easiest way to fix the bug was just to create and use a new ‘paged’ container instead of a vector to ensure that growing the container would never invalidate references. If it had been written in rust from the get-go, that code would have failed to compile early on, long before so many dependencies were written on top of it!
RAII must be one of the biggest misnomer in programming. The core of the concept is not to bind resource acquisition to the initialisation of a variable. But rather to bind the resource release with the destruction of a variable.
The core concept is to bind the resource lifetime to a variable lifetime. This includes both binding the resource acquisition to the initialization of a variable and binding the resource release to the destruction of a variable. That's why languages without constructors like Rust cannot fully implement RAII as they cannot bind the resource acquisition to the initialization of a variable. The resource has to be acquired and then binded to its RAII variable, if stack unwinding happens between the resource acquisition and its binding, the resource won't be released.
@@hanifarroisimukhlis5989 no stack unwinding does not cause resources to be released. It just destructs variables. If a resource isn't held by a RAII variable it won't get magically released. Releasing resources can mean anything like making a system call, sending USB data to a device or sending a network packet to a server. Rust, or any language, cannot do that on its own that why we have RAII: to make the system call/send USB data/send network packet in the destructor of a variable which holds the resource.
@@hanifarroisimukhlis5989 I think he meant if an exception occurs between (for instance) a malloc and setting the field RAII-variable. Then we would get a memory leak. Which is true, but it would be true of any RAII system. The resource allocation and the binding cannot be made in one atomic step. And my point was exactly this. We dont actually really care about the specific details of the steps to acquire a resource. What we care about is that the bulk of the code cannot leave a resource unreleased. Also, it doesn't actually matter if the variable initialisation happened miles before the resource is bound to the variable. As long as it is bound ASAP after it's been acquired in order to avoid the case mentioned above. Hence, it'd be better called DIRR. Destruction Is Resource Release. Or RRID. You know what? Let's try to popularise those names. 😆
@@Ceelvain In rust it definitely doesn't matter whether the value is bound or not to whether there is a gap in which a panic (aka exception) can cause a memory leak. There is no gap, when these things are lowered to the low level intermediate language all temporaries have bindings and drop elaboration happens at this level. All possible code paths are covered, including the panicking ones.
After learning Rust, my best advice is to write it without using borrows at first. Do a lot of copying and returning new objects. It is not efficient but it trained my brain to think about the memory allocation and moving process. Then borrows felt like a natural optimization.
So Bob has a constructor called Foo? And the scalar delete operator is used in the destructor to delete the array allocated with operatot new[]? And b gets automagically renamed to bob in Rust? I guess we are dealing with a computer scientist here.
2:37 This is NOT the same as in other languages. Val in Kotlin, final in Java, etc. makes the variable itself not reassignable not immutable. final var person = Person(19); person.setAge(20); does mutate the variable even if it has final. In Rust, however, you cannot* mutate the variable at all (as for age_set(u16) you would need a mutable reference). (* ignoring concepts like internal mutability using RefCell (assures the 1 mut xor n imut rule at runtime instead of compile time), unsafe and such)
What I've realized by studying different programming languages for around 5 years is that the harder the language, the better "programmer" it makes you in the long run, I think a lot of people can code using a language like python or JavaScript, but very few could even begin to understand the many rules and regulations of low level languages. Unless you're absolutely stubborn about learning a low level language, you won't be able to cope with it
ˇ2:45 : Well, C and Java also have construct to declare something to be a constant. All Rust does is make "constantness" the default, and one has to specify mutability ("variability") using an additional keyword. It's not like other languages are like Fortran V on Univac 1100 series under EXEC8, where even integer literals were actually mutable variables passed to subroutines by reference. Now, _that_ was a source of some really nice puzzles for novices.
Rust doesn’t actually prevent memory leaks. It is fully possible to leak memory in safe rust, although a little harder. This is demonstrated by std::mem::forget, which was at one point unsafe, but after a while it became clear that preventing memory leaks entirely was unpractical in a language like rust, due to e.g. reference counting cycles or deadlocks or tons of different things
6:21 - You have an error. You didn't use the right form of delete. You need to delete arrays differently. In this case, it probably will be just fine. Also, you keep saying "C" and then using "C++". They're different languages. Lastly, the appropriate comparison is not to bare C++ pointers. I hardly ever use those anymore in writing C++ code. The proper comparison is C++'s unique_ptr and shared_ptr. The concept of mutable and non-mutable borrowing doesn't exactly exist with those. But those are the closest equivalent to what Rust is doing.
GC is the single worst cause of headaches in my job. I'm a senior programmer who works on video games, and I mostly deal with low level optimizations. An unreal GC collect call is going to cost 125ms on a switch. This is just for a call to GC.Collect, there might not even be any garbage to collect. Yes. that's 10 frames at 60 fps spent just looking for things to free. RAII amortizes these costs so they are hit at the moment they are freed. Spreading it out.
Okay, but it's not C++. No one writing programs like that in real life. There are tools which will help you to find different kinds of errors. Clang-tidy, Valgrind, PVS Studio, compiler flags like `-fsanitize=address`, maybe something for MSVC from Microsoft. Clang-tidy, can analyze code in real time, it's easy to use, and built in in CLion IDE, can be easy installed in Vim/Emacs with a help of LSP and clang tools. And of course there are unique pointers and move-semantics since 2011. Rust is cool, but C++ does not stand still.
Waited for a quite a while to hear "Rust isn't a niche language". Also it has name for it's memory management system - OBRM (Object Based Resource Management)
Writing C-with-classes and calling it C++ (in that you didn't use std::vector, which is the proper approach to this code) is a bit of a hatchet job. What Rust has "built into the language" is literally right there in C++ just the same. I know examples are usually contrived but like damn dude.
9:20 I would actually say the inverse here: at best the program crashes, at worst it gets some garbage. In my experience, debugging with garbage data has been much more hellish than immediately getting a seg fault and knowing the exact location of the problem.
The code is bad, but it's also more code than necessary. He had to go out of his way to make an issue, whereas one std::vector would have solved the problem.
I think you're forgetting the audience this video is for. A lot of people watching this don't know about rust, c++, or memory management, and they aren't going to be coding embedded code any time soon. He just needed to demonstrate clearly and quickly the memory management problems that Rust's ownership model is trying to solve. This isn't a sales pitch for programmers, it's educational content for laypeople.
It's really easy for a new programmer that doesn't know about smart pointers to fall for those traps. If he wanted to make that point he probably should had used C. Rust is better than C++ for other reasons so you're right, no need to write bad C++
The point is also that you *can* write memory unsafe C++, despite following rules like RAII, whereas you can't in Rust, unless if you write "unsafe" somewhere. He could've presented an automatic code analysis tool for C++ that implements the move/borrow semantics and gotten to the same result, but rust has that tool built in and a syntax that is built around the move/borrow semantic, so why not use that instead.
I spotted a mistake in his code. The constructor and destructor should have the same name as the class name. Here name of class is Bob and you named the constructor and destructor as Foo
6:00 this is Undefined Behavior btw, you are not allowed to call delete on a pointer allocated using new[] Correct way to free it would be delete[] this->n;
Great content, but a bit hard to follow. All the func_n examples introduce unneccesary cognitive load here. Also it would be great if it was being presented with live compiler messages. Showing exactly what the Rust compiler would be telling us if we were using an IDE.
This video is way below Computerphile standards. In your series the presenter dives so smoothly into the foundations of the matter and explains the core logic behind for total n00bs. All I understood from this video is how cool Rust is because it's the same as C++, but opposite. There must be a reason it's so popular, but the video failed to convey it.
Mother of Code. For all my love of Rust... * Foo() is not a constructor for class Bob... Surprise... * In C++ there's a **strict** difference between "delete x;" and "delete[] x;". You used the wrong one. * Hardly anyone writing a fresh codebase with sufficiently modern C++ would use field "int*" when they can use "std::vector". EDIT: And of course, in Rust you can have a block of memory that has no owner. That's what bare pointers are for. That's unsafe{} but possible.
6:30 no, you don't have to write that urself, that's where stl comes in: we have generic containers, like std::vector for storing generic data, std::string is a text container and std::unique_ptr\std::shared_ptr are RAII wrappers, that do basically the exact thing you've shown: it would allocate an object for you, keep track of the memory and delete it, when the object(or all of the objects, that point to the resource) goes out of scope.
he's also doing it wrong. He's meant to delete[] because he allocated a sector of memory, not a single element. In most unix systems and linux distros that is not a problem because the allocator used works just fine either way, as it simply writes how much memory has been stored using a size_t chunk of memory just before the first element. But in the case of windows for example, that is not the case, the allocators are different, and many other systems could be using a different allocator, so using a delete there is UB. More evidence that we should not blindly trust all the things we're told by people on the internet.
I think something that was a little left out ist that you can do most things with rusts RAII principles (except for multiple owners, so reference counting). If you want to free some memory halfway through an objects lifetime, you can give the Memory to an `Option` which does runtime checks on the variables validity, which your Object then holds onto. This then forces users of the object to consider whether or not the memory is valid at that current time. In rust you very rarely actually need `unsafe` blocks, unless you're doing something like embedded programming or unsafe magic. Also rusts reference counting doesn't actually violate the one owner principal, since the reference counted "backend" owns the original data (in implementation this isn't quite correct, there is an UnsafeCell backing all of this, but for the users purpose this doesn't matter)
the problem with garbage collection is much more then its cost in resources. It doesn't solve the general problem of resource management and in/out operations. because with garbage collection the time and ordering of destruction is not unspecified. so any resource that has side-effects in its destructor is usually not safe to run during destruction. RAII and rust's Drop traits solve this issue by having a per-determined ordering of destruction. so RAII is used in C++ for many many things: management of memory, lock/unlock mutexes, timing scopes, management of OS/external handles, unhandeled error detection, parser scope tracking, statistics tracking, post-condition checking......... also this video makes it sound like RAII must always be done by hand in C++ which is wrong. Most of the time libraries have the utilities with the behavior you need an you can reuse them. rust's Box should be compared with std::unique_ptr. not doing it by hand.
C++ arrays should be deleted with `delete[]` operator @ 6:04 , this is because over-allocation or an associative array technique is used to hold the number of elements in array, so you need to hint the compiler to de-allocate the latter too.
java and c# devs will argue about design patterns and their own personal dogma on the only "right" way to code until the cows come home. C++ devs only say 4 letters, RAII.
The C++ code given as an example here compiles fine (change the name "Foo" for "Bob"). It shows clearly that you can mess up things easily in C++ and other traditional languages. I know that there are now better ways of writing this code in modern C++ to avoid pitfalls, but the point here is to show how safety tightly bound into the language itself can address these quirks, but I admit a better programmer can do as well ...
if you do a new[] please do a delete[]. Even in a so simple example bug has creep in. Furthers proof that most programmers should not write this kind of code themself.
It's pretty basic stuff that any half decent programmer should get right. It bugs me when people blame such things on the language. Like blaming a car for driving the wrong way down a one-way street.
I don't know any rust. Isnt the ownership principle the equivalent of using std::move on a unique pointer in c++ only here it's the default pointer behavior?
The differences are: Moves are the default, deep copies (called clones) are the explicit alternative. Also moves are "destructive" where the compiler doesn't let you access the variable anymore. In C++ moves put the object into a "valid but unspecified" state, which is a little bit odd for types that don't necessarily have such a concept. Like what's a valid but moved mutex, thread, file, tcp stream, etc? For a lot of types there's an equivalent of a null value, but for those that I mentioned the classes need to do some special "bool is_moved" or so and probably throw an exception on all the methods? It's really weird.
Do not forget the RAII doesn't help the heavy lifting of resource ownership juggling. In non-GC realms the language users still have a burden of ownership management to think of, one way or another, whereas the GC does it all.
unique_ptr is called unique for a reason. He would've had to create a (deep and expensive) copy of the vector to resolve the problem if he used unique_ptr (or vector). The solution would've been shared_ptr, but even that has a runtime cost, whereas in Rust it would've just been a completely free borrow and no unique_ptr / shared_ptr at all.
You can create a std::unique_ptr and move it around to pass ownership or pass it by reference to allow borrowing of it. Its the point of unique_ptr. Its what it does.
@@Guru4hire Yeah but that misses the point of the example in the video. The example was that Bob had ownership and got destroyed and there was a dangling reference to the numbers still. unique_ptr wouldn‘t have helped here at all, unless you would‘ve moved out the numbers, but that‘s not what he wanted to do, he wanted to destruct Bob.
I think I understand the point of disagreement now. I am saying that a unique_ptr to a class or struct bob which has a public unique_ptr to a vector of ints performs essentially the same as all the rust code examples. I would argue that the pathological get_n function (which is not in the rust example) in the c++ example would fail to compile as the unique_ptr's copy constructor is deleted. I would have liked to see how Rust handles the contrived use after free bug with the get_n function.
@@Guru4hire one other thing is that C++ unique and shared is a runtime cost where Rust is a compile time check. C++ compiles down to pointers allocations and checks where rust just compiles to pointers.
Yikes. At 4:53... The constructor should be called "Bob" since the class is "Bob". Also, you shouldn't use "this->n". It should be Bob(int x) : n(new int[x]) {}
great feature, i wish rust had Java like readable syntax, mimicking C was definitely a mistake. C syntax is horrible but probably devs comes from C background.
One of the things I have never understood about rust is how to do something like a read write queue. There are many cases were we pass immutable as a way to create "Read-only" memory for a part of the program but not that its immutable. By this logic, we can easily make a concurrency queue and pass it to all the workers, but any attempts add any jobs will then be stopped as you would be mutating a queue which has borrowed references.
The thing you are missing is that the mutable vs immutable reference in Rust is a misnomer. What they actually are is unique vs shared reference. It is possible to create types that can be mutated through a shared reference. A prime example of this is mutex.
It would be nice if the code actually compiled (C++ class Bob having constructor and destructor named Foo: no) or does what we're told it is supposed to do ( in rust Vec::new() doesn't allocate anything. It creates an empty vec - such a vec starts allocating in push).
Rust’s borrow checker is one of the most powerful and strict features of any language I’ve ever used, and it’s absolutely wonderful!
Let's make a Groovy for Rust so we can ignore all that and turn it into an interpreter.
@@nicholas1460 absolutely! Lets bring gstrings everywhere!🎉
@@alucard87 The pervs have surfaced. Anyone has anything to do with the Groovy language is responsible for what they do.
meanwhile, every rust user: "unsafe { ... }"
There's stricter features in Dafny, but I'm not sure those are "absolutely wonderful". They certainly are very interesting though.
9:19 I would say exactly the opposite, in this situation the best for your program is to crash, the worst is to get garbage and continue as if nothing had happened as it might takes months, years or decades to find out such a problem (especially when dealing with processing data and not knowing the kind of output you should expect). What usually happens, though, is that you get intermittent crashes depending on the memory values you get from that dangling pointer.
Pretty sure the constructor and destructor in the C++ version needs to have the same name as the class, but that's besides the point of the video.
I was gonna write that. The best case for a UAF is usually a crash, rather than silent data corruption, or revealing random memory. Both of them are security/safety risks, which can undermine everything your program does.
Yep. When things break loudly, it's a big motivation to go fix it. You can also log exactly where the crash happened and the state to track what caused it so you can prevent the problem in the future.
Fail early and loudly
this! crashes are problems that actually got *detected* and *prevented* - crashes are your friends
💯 The development time (money) involved in debugging the garbage cases is dramatically larger than failing fast.
09:20 - it's pretty much the other way around. Best case - your program crashes, worst - you get wrong data and use it.
Depends on the program, where exactly in the program this problem appears, and how often it does so. For example if the value was storing the color information for a single pixel, and that value is garbage once every 10 million outputs, and all the program does is display images on the screen, I'd rather have that single pixel flicker with random colors once every 5 frames than have the program crash. At least as a user.
@@256shadesofgrey This thinking is what leads to scanners giving you wrong numbers in your tax reports, look up "Xerox randomly changes numbers". The program should crash and make the developer fix it immediately, not try to ignore it forever.
@@256shadesofgrey Hehe, fun fact about Undefined Behavior - you just can't assume what would happen when it is triggered.
As an example: you program might run on the same amazon cloud server as some Radionuclide therapy-software, and UB in your code might trigger some unknown exploit that breaks vm isolation and corrupts command list for RNT device.
5:50 in C++ you need to tell the compiler if what you're deleting is an array with delete[] instead of delete. In that example the memory won't have been freed properly.
I guess this just goes for show on how easily memory leaks can happen when the programmer is responsible for the memory management.
@@LuizDahoraavida Just use std::vector.
@@LuizDahoraavida now you're getting it :) this is why rust was created in the first place: to eliminated a whole class of bugs caused by common and easy to make mistakes
I just hope that wasn't on purpose
@@seth3129 std::vector already existed from the beginning.
That "bob" variable you tried to use three times doesn't exist.
And why not show the compiler output? It's very friendly
Exactly. I was going to ask this. I kept searching for where it was defined since the argument passed was “b” and none in func_1.
It’s not a rust tutorial, it’s explaining the idea of a borrow checker which it does fine
Thanks for clarifying, I was thinking if somehow 'bob' and 'b' are the same variables...
@@-dubu Still wary of learning anything from someone who doesn't appear to know what they're doing.
This kind of sloppiness does a real disservice to the channel and the intent of the video. You can't be bothered to COMPILE all your examples? Or at least "*" annotate the errors in the video? Such obvious errors are a disappointing distraction that pollutes the message.
It seems a little apples-to-oranges to have a raw pointer in C++, but have a vector in Rust. Both of the languages have a suitable vector type that uses low-level operations under the hood and packages that up into a nice-to-use type with the hard work done for you. Using the video's examples for the two languages makes it easy for people who aren't familiar with them to walk away with a very incorrect view of C++ that remains pervasive in the field, but doesn't reflect how ordinary code is written at all. The Rust comparison should come in at the point where it starts to offer more guarantees and functionality than what C++ can offer, and point out that it's part of the language rather than static analysis.
Even moving (which C++ has too, just different) isn't so much about one owner for something like a vector (the vector already represents a single owner of its memory) as it is about not needlessly copying the vector. Either way works, but one makes copies explicit. There are other contexts where it's more about a single owner for a resource. Borrow checking and trying to use something after it's been moved from are where Rust really starts to bring more to the table in this regard than static analysis with accompanying rules on how to write code so the analyzer can reasonably work with it.
This is the same problem I have with most Rust vs C++ comparisons -- you get someone who appears to have virtually no knowledge of C++ that isn't at least two if not three decades out of date confidently saying why their insanely contrived example that no real person would ever do could be better in Rust. I strongly suspect there are things that _would_ be nicer for me in Rust, but instead I just keep seeing crappy Rust salespeople that don't know any C++ but try to pretend that they do.
This person doesn't even seem to know how the very basic fundamentals like how constructors and new/delete works (this feels too extreme to be live-demonstration nerves, and insane they didn't doctor it in post), so I'm very doubtful they ever knew anything about C++ at all.
From what I understand, most of what Rust brings to the table is advanced static analysis, which is great, but C++ has a decent amount of that too (e.g. use-after-move or use-after-free).
Yeah, happens a lot. I find a lot of Rust programmers are super into it, espousing all of it's pros, why everyone should use it and usually comparing it to C++. There's also an element of functional vs object-oriented where they all espouse functional or functional-style programming to be *always* superior to OOP despite the fact that OOP is still one of the most common programming paradigms in the world. They all seem to be drinking for the same fountain that says "this is why Rust is better than C++", but don't actually know anything about C++ beyond the base language and usually the 98 standard.
Rust is kind of a cult and those who love it think every other language is terrible, especially C++.
Personally, I love Python and C++, but I'll use whatever suits the task best.
@@claytorpedothe advantage of rust isn't that it *offers* static analysis, it's that it *forces* static analysis by default.
Someone who knows very little C++ is very likely to make this sort of mistake without knowing how it could've been prevented.
Someone who knows very little Rust won't make this mistake because the compiler defaults don't allow for it.
The video is not demonstrating the Best Practices of both languages and how THEY differ. It is demonstrating the MINIMUMS of the language and how they differ. You can constrain C++ to get much of the same benefits as rust, with the added boilerplate, static analysis configurations, and code-style enforcement that comes with that. Even with all those things, it is still POSSIBLE to create these kinds of bugs because the language allows these unsafe operations BY DEFAULT and won't warn or flag that you are doing something that may cause issues. In rust, if you wish to do these types of operations for the few valid use-cases where they are unavoidable, you HAVE to tag that block as unsafe. In the event of a crash, that is going to be the FIRST place you look.
@@trapfethen Thank you for providing a balanced analysis.
I like how neither his C++ or Rust code snippets would compile.
correct hahaha
The C++ has extra sneaky [Undefined Behavior] too, because he used `delete` instead of `delete[]`.
I was wondering about that... I was thinking "surly they would have caught that, maybe it is a new feature in C++, the constructor can just be called Foo"
That's what 'pseudocode' means. It's for other fellow humans, not computers...
Needless to say that is just for the purpose of explanation
Even though the goal here was to demonstrate Rust RAII mechanism, it's worth mentioning that modern C++ provides equivalent concepts using unique_ptr and moves. Nowadays, you rarely need to delete memory manually in C++.
You can still get dangling references pretty easily. Rust solves this with lifetime analysis. This can often be picked up in c++ through static analysis but Rust guarantees that dangling references won’t compile. The c++ is very poorly constructed - just accessing the data() function of std::vector would have been a better example to construct a dangling reference.
It's the usual Cult of Rust propaganda: Rust is the best, everything else is bad, especially C++
@@TheJaguar1983 C++ Stockholm syndrome in action
@@slyfox3333 Typical one-eyed Rust fanaticism.
@@TheJaguar1983 cope
This video conflates RAII and ownership semantics quite a bit. This is a common misconception but if this is meant to be an introduction to either concept, this will most definitely confuse a newcomer to these concepts. You can explain Ownership Semantics without ever referring to RAII whatsoever and vice versa. Ownership semantics can be used to aid with a few issues that RAII in C++ causes (such as over use of copy constructors) but they solve different orthogonal problems entirely.
C++11 onwards also has all of these ownership semantics (rvalue references, std::move, std::forward, etc), but they are an opt-in thing rather than something that is required like in Rust.
Also, if you are wanting to reduce resource usage as much as possible, RAII is not the right tool for you and will most likely cause you to waste more memory than other approaches.
How does RAII cause you to waste more memory?
RAII don't waste any resource, it's just a method to handle object states.
I'm not sure I agree at all. This video isn't confusing RAII and ownership semantics at all, but is illustrating how RAII must be handled and enforced for it to work properly. To allow RAII to work at all, the borrow checker/ownership semantics have to be enforced.
How is this conflating RAII and ownership semantics?
I'm also unsure how RAII is "wasting memory" to be honest. Rust automatically drops things that go out of scope, but you can also drop things at any point.
@@noahhounshel104 @kwanarchive @Zsombor Hollay
RAII on its own does not necessarily waste memory compared to other approaches, however the general culture assumes RAII means you should allocate singular things instead of thinking about your allocation separately from your single objects. As a result, a lot of memory is wasted because you off-load the allocation aspect to the single object, whereas RAII could still be useful if you did not do this.
Another issue with C++ specifically is that they conflate construction/destruction with allocation/deallocation. It is extremely useful to want to allocate an object and then construct it at a later time, destruct it and then deallocate it at a later date, but due to the way C++ has been designed and the culture around C++, most people couple them together (making things bad). Constructors and destructors also do not "return a value" meaning that the only way you can signal something may have gone wrong is by throwing an exception (which might be a huge issue depending on the problem space). This is why many people will just use explicit `init` and `destroy` functions/methods instead of relying on the ctors/dtors, thus bypassing many of the features of RAII.
I can give you loads of real world examples of codebases that use RAII heavily that are extremely wasteful of memory (compared to other approaches). And to clarify, RAII is not inherently wasteful but the culture around it and how it the languages that have tend to be designed nudge you to use it in such a way that is extremely uncaring about memory allocations by making them hidden.
@@GingerGames Eeehhhh. I suppose you can view RAII as "wasteful" if you are never deferring the creation of the objects to a later date, but in the Rust world doing so would just be an Option which is useful/important for a whole host of reasons besides having deferred allocation.
The reason you can't borrow mutably and immutably at the same time isn't because one function is expecting the data to be unchanging while another is expecting it to be mutable. If that was the case, as you are presenting, multiple mutable references would be allowed at the same time, when they very much aren't. Mutable references are meant to be exclusive so there's only ever one point of mutation for a given piece of data (and no immutable references at the same time), which is done in order to avoid data races and the such. This is why mutable references are often called exclusive references and immutable references are often called shared references. This principle is also applicable to `Rc`, which was mentioned. Rc basically gives shared references to the data, but it cannot be mutable; to have shared mutable data, one would have to use one of the interior mutability data structures (in the case of an `Rc`, you'd probably want a `RefCell`).
I think it's important to make this clear when introducing the topic of references in Rust, because one of the core design principles is "fearless concurrency", and as such that is baked into its fundamental ownership principles. That is to say, these concepts are inherently tied in Rust. I don't know if this was an intentional simplification, but it's something that shouldn't've been omitted imo.
As an aside, `Rc` and `Arc` aren't really like garbage collection. Like, they can be used like garbage collection, but basically instead of having a garbage collector go through the memory and seeing what should be dropped, `Rc` and `Arc` keep an internal counter and then increment it when cloned and decrement it when dropped. When an `Rc`/`Arc` is dropped and there's no more references, it just drops the underlying data. This means that using these smart pointers has a slightly different cost to the equivalent code in a garbage collected language. (Though this isn't really a major point.)
GC is not just mark and sweep. Reference counting is a form of garbage collection
I was going to post the same comment but you worded it better than I could have 😅
also having multiple mutable references might cause data to become invalid. imagine taking a eference to the first item in a vector, and then overtiting the vector with an empty one. now our reference points to unitialized memory
Basically you pretended to "fix" something the video doesn't say in the first place, and failed to do so. I am used to this pointless pedantry on StackOverflow: not ready to face it here on YT, frankly.
@@valcron-1000 I think the term GC is often misused that way, but I don't think it's correct. Python, for example, has a garbage collector, but it also has ref counts, and the GC is only there to clean up things the ref counting can't handle fully (like cycles). You can't have garbage collection without a garbage collector, and Rust definitely doesn't have one (any more).
Shouldn't the constructor be 'Bob' not 'Foo' though?
I've not coded in C/C++ for a long time and I was having an aneurism when I saw that and wasn't sure if the code was wrong or my memory. Thanks for the comment letting me know I was right!
I think its the other way round, the Class should be called Foo, not Bob…😊
@@Am6-9 yeah, Bob should be called Robert
Shouldn't constructors in C++ have the same name as the class?
If this was the only error in this video. Most variable and parameters names were wrong in the Rust example (n becoming bob, b, becoming bob, etc.). I liked the video but it was a mess. Trying to compile the code to show what it does would have allowed to detect those problems.
@@Hexalyse also delete instead of delete[], among other things, filling this video with tons upon tons worth of UB.
@@Hexalyse That is the issue with academic CS though. They are more interested in concepts and less in being code monkeys. They can design the most complex ideas and constructions, but in the end the people that work with the language on a daily basis will know a language better than they do.
@@Hexalyse It seems to me like all, or nearly all of these errors would have been caught if he just tried to compile his code after each demonstration. And actually *demonstrate.*
But to be fair, he seemed a bit nervous in front of the camera and I don't blame him for getting lost. Next video will be better, I'm sure of it :)
@@Hexalyse Explaining and coding at the same time is not the best option for everyone I guess! 😆😁
Probably it would have been a better idea to first write and test all code first before showing it in a presentation.
Explanation was fine though.
Some of the things Rust does the right way:
1. RAII or memory ownership model - follow few rules and forget about memory leaks
2. Traits composition instead of trait inheritance.
3. Powerful enums/unions - can hold values. You have to consider all cases
4. Pattern matching
5. No NULL. Instead - enum with optional value
6. Powerful macros
My main complaint with rust is that compiler won't let me be silly and write bad code. This also means it won't let you shoot yourself in the foot. But the learning curve is a bit steep. Rust is so different from other languages
Rust is inconvenient to prototype things in. That's probably why we see a lot of Rust rewrites of existing programs, that already got prototyped decades ago.
@@ifcoltransg2 for some stuff. though, i actually find myself specifically leaning to rust to prototype in, because the way one lays state out makes it a lot easier to understand how the program would work, for me
@@0x5DA I did overgeneralise. I guess Rust's type system is great when you want to make sure things end up correct and well structured. It gives you some support there to create a solid foundation. But I do find, for the kind of project you just want to get working, it's easiest to throw up some Python onto the screen first, rewrite it in a type system after.
@@ifcoltransg2 i get that, for making it work! no worries
@@ifcoltransg2 After using rust for personal projects and then nearly a year in production, I now find it much easier to prototype complex ideas in.
The biggest help it provides is in easily helping you design your data model in a way that your program can never reach an invalid state (mostly thanks to the absence of null or similar and the conciseness of enum variants).
Nowadays when prototyping something I usually go to Rust first because I know that if there's a lib to do what I want it'll 9 times out of 10 (if not more) have standardized, easy to navigate documentation and the auto-completions brought about by the strict type system will guide me through the process.
I do agree with the OP on that it takes quite a bit of time to learn and even more to become actually proficient in it (not even mastering it, just being able to "realistically" pick Rust for a time-sensitive project); I wouldn't ever recommend it to someone as a first programming language.
It’s worth noting that rust has type inference, so you don’t have to specify your type every declaration of a variable
@MenaceInc Well it would be a shame if it doesn’t 😂
@MenaceInc While you’re correct, C++‘s type inference, which is similar to Java’s, C#’s, etc. isn’t _quite_ as powerful as Rust’s, which is more like those found in functional-first languages. For example, in C++, you can’t write something like “auto x;”, while “let x;” is valid in Rust (provided the type of x actually can be uniquely inferred by how it’s used).
If you have rust-analyzer installed you also get phantom type hints inline with your code which makes it so nice to read. No need to hover over variables to see the type like other languages. This seems small but it's so nice.
@@NuclearCraftMod That is not a problem of language but of compiler standards.
@@konga8165 Many of the popular languages's LSPs have that kind of functionality though..? It's just returning more information to the editor following the LSP standard.
Thank you for this explanation of RAII, it was really interesting. But nearly all examples shown wouldn't run as either variables or methods are wrongly named. (Foo constructor in Bob, bob instead of b in all rust functions)
I think this was explained quite poorly. You can write as much garbage code in any language you want, including rust. What matters is that when you try to compile the code, the rust compiler rejects much more (memory related) garbage than the c/c++ compiler does. Whereas c/c++ will allow you to get to runtime and may or may not crash then, rust doesn't allow you to get to runtime at all until you have fixed these issues. And not once you showed any compiler output at all. Which is also probably why you kept using variables that don't exist at all.
Rust is like switching to a properly strictly typed language after coding in some poorly typed codebase in a gradually typed language.
I work as frontend and I've started using Rust because I was missing messing around a low-level language. I'm in love! It's harder than JS (and way slower to build anything) but the borrow checker and the compiler are so so so good.
just use c++ rather than an esoteric language like rust
21:01 You also can't have a mutable reference to an immutable variable, which Ian had at this point. And regarding mutable and immutable references, it's not just that you can't have both of those, you can't have _any_ other references, mutable or immutable, if one of them is mutable, for similar reasons. (It's a little more subtle, though. For these purposes, Rust only cares about the span of execution when the variable is actually used. That's why the example with moving an object from one variable to another is fine, because after that the first variable isn't used. In the same way, you can declare and use multiple mutable references to the same object in the same scope, as long as the regions where they're used don't overlap.)
Huge fan of Rust. I've been writing it in production for over a year now and it's been a dream to work with.
Great video. One remark would be to try compiling your examples next time. I think people unused to these languages could become confused when the code isn't accurate.
Nice video, the Rust borrow checker is pretty cool, but the C++ comparison didn't make much sense. C++ has had smart pointers for 12 years now (maybe more with boost), which get rid of all the problems except dangling references. You never write new and delete in C++, you never use raw pointers that own memory, you can move or only "borrow". The only thing where standard C++ will not help you is if you borrow a pointer and try to access it after the owning pointer deleted the memory (so dangling references).
Smart pointer still sucks though. Not everyone will use it, and adds complexity. Atleast Rust understands what you're doing and prevent errors before you spend hours debugging.
There are a few more things C++ won't help you with but yeah, this was kinda strawman argument.
C++ has had RAII capabilities since the 80's even, it was just made more nicely with the addition of move semantics.
I still use new and delete and never have a problem with it.
@@hanifarroisimukhlis5989 Not true. Smart pointers are excellent. On the other hand, the time you save on debugging with Rust, you waste fighting the borrow checker.
Your constructor and destructor for class Bob should be Bob and ~Bob, and not Foo and ~Foo.
If you allocate an array with new, you need to use delete[] to clean that up, not just delete.
In your rust code, you refer to bob when you variables are named n and b. Maybe you should get an IDE that highlights errors for you. Vim is great and all, just use syntastic or some other plugin to do that for you.
Bare pointers are fine so long as it's simple and easy and there is no chance of accessing memory after it has been freed or it being very unlikely that you forget something. You should just use smart pointers instead otherwise. Unfortunately something that starts out simple can quickly grow in complexity and if you are not careful designing your API to your bob instances, someone might pull a pointer and use it outside some scope. Instead of trying to remember to allocate and clean up in two different spaces, you should just let the smart pointers handle that for you. They are well optimized. They do of course have their own drawbacks like cyclic dependencies that need to be watched out for, but generally they are the better choice.
In your Bob example, a unique pointer would simply not work as you can't copy it without handing over ownership, and a shared pointer would work just fine, although you still wouldn't want to just return it like that as n probably makes no sense without bob. A weak pointer is probably the right choice here.
If you want a fair comparison, then bob in c++ would also hold onto a high level structure, like std::vector, instead of a bare int[].
Err, no, an array of int would be represented by int*.
int *x = new int; // fine
int *y = new int[5]; // also fine
delete x; // correct delete for single item
delete [] y; // correct delete for array
int ** would be an array of array of ints or a way to pass an array by reference in a C-style function so that you could (re)allocate it.
But you are right about the rest, std::vector is almost always preferred if you need a dynamic array, or std::array if you don't.
@@oracleoftroy fixed it. you are correct.
6:32. RAII doesn't put allocation/deallocation as work on the programmer. The programmer can use STL containers and pretty much never use the keyword new. It is called rule of 0 and is the core essence of modern C++.
This is a very thorough explanation... thank you for that...
But I must point out that at 5:45 inside the cpp program, within the destructor, the use of the delete keyword (delete this->n) in order to deallocate the array is wrong since it only removes the first element as the array is technically a pointer, therefore you would have to use the delete[] keyword (delete[] this->n) or loop through and delete each element.
Thank you for this wonderful video ❤
rust newbie here, this is possibly the best introductory explanation to the rust borrow checker i saw on the internet
So long as a mistake can be made, it will be made eventually.
To me that's one of the greatest strengths of Rust. It prevents you from making common mistakes by being opinionated enough in it's design.
What wasn't mentioned is that the C++'s standard library is build around RAII and the notion of moving data around, so the concept is not new for Rust. Rust just enforces it by the compiler, while C++ lets you use RAII as well as unsafe resource management.
Rust programmers tend to not know that because they're too busy running down other languages' flaws
The explanation was perfectly fine for me, on point. There are millions of other channels to learn about the syntax 👍
This guy knows neither C++ nor Rust.
You absolutely wrong when tell about C++. C++ already has RAII classes in STL, and in most cases you do no need to handcraft memory management.
Also, resources are not only the memory, as other commentators mentioned, it might be any thing what you get from OS, like: window handles etc.
The key difference in C++ and Rust is move by default in rust, and borrowing.
I've been learning Rust this last year. Love it.
Immutability works much differently in Rust than in TS. In TS, when dealing with non-scalar values such as objects or arrays, a const won't allow the value itself to change (e.g. memory address), but you can still push to an array or add a property to an object. In Rust, it's an effective Object.freeze by default where you still need to declare "mut" to allow modifications to the underlying compound value. This is a very important distinction.
Lack of mut in Rust is much closer to const in another language... C++. When applied directly to an object (like a variable), the meaning is basically the same in both languages (but there is a significant difference when applied to the type of a reference). Whether for the presenter's lack of C++ expertise or another reason, this video makes it look like the difference between C++ and Rust is many times greater than it actually is.
So, in the C++ sample you use raw pointers and manual memory management, which is not recommend in modern C++, and you could use std::vector and return it by copy, move or const reference then you'll get the same behavior as in Rust or whatever you can want 🤷
And don't forget about references in C++ too.
However, I agree that more control that C++ gives to developer requires a lot more responsibility.
The C++ code is wrong in the video. First off, the constructor name. And also, in C++ if you allocate an array you gotta use delete []. The concepts were explained somewhat vaguely. I recommend anyone trying to learn this, trying to the same stuff you do in C++ just write in Rust, and the compiler will automatically guide you towards the right way to do things. In C++, it will just let you do that stuff, no problem.
The "many read-only or one read/write reference" rule is also part of the dangling pointer protection. Imagine you have a Vector with a bunch of elements, and you take a reference to one of those elements. Suppose you were to now extend the vector. In that case, you might exceed the allocated capacity, causing the whole thing to be moved to another place in memory -> your reference to the original vec (which has now been deallocated) is now invalid. Besides that, not allowing two mutable references also prevents data races, which are considered unsound in rust.
It might also be worth mentioning that memory leaks are not considered unsafe or unsound in rust and are totally possible with safe rust(Box::leak, or having reference counted smart pointers point to each other in a loop like Rc1 -> Rc2 -> Rc1).
The vector case you mention is critical. I’ve had bugs in a C++ program just due to passing a reference to an element on the stack along with a reference to the object containing the vector. Way farther up the callstack that vector grew and the reference on the stack got silently invalidated.
Because of how complex the code had grown, going back and refactoring to eliminate this ‘unsafe borrowing’ was completely impractical, and the easiest way to fix the bug was just to create and use a new ‘paged’ container instead of a vector to ensure that growing the container would never invalidate references.
If it had been written in rust from the get-go, that code would have failed to compile early on, long before so many dependencies were written on top of it!
RAII must be one of the biggest misnomer in programming. The core of the concept is not to bind resource acquisition to the initialisation of a variable. But rather to bind the resource release with the destruction of a variable.
The core concept is to bind the resource lifetime to a variable lifetime. This includes both binding the resource acquisition to the initialization of a variable and binding the resource release to the destruction of a variable.
That's why languages without constructors like Rust cannot fully implement RAII as they cannot bind the resource acquisition to the initialization of a variable.
The resource has to be acquired and then binded to its RAII variable, if stack unwinding happens between the resource acquisition and its binding, the resource won't be released.
@@gehngisnot really, when the stack unwounds the resource is dropped/released, unless releasing such cause further exceptions.
@@hanifarroisimukhlis5989 no stack unwinding does not cause resources to be released. It just destructs variables. If a resource isn't held by a RAII variable it won't get magically released.
Releasing resources can mean anything like making a system call, sending USB data to a device or sending a network packet to a server. Rust, or any language, cannot do that on its own that why we have RAII: to make the system call/send USB data/send network packet in the destructor of a variable which holds the resource.
@@hanifarroisimukhlis5989 I think he meant if an exception occurs between (for instance) a malloc and setting the field RAII-variable. Then we would get a memory leak.
Which is true, but it would be true of any RAII system. The resource allocation and the binding cannot be made in one atomic step.
And my point was exactly this. We dont actually really care about the specific details of the steps to acquire a resource. What we care about is that the bulk of the code cannot leave a resource unreleased.
Also, it doesn't actually matter if the variable initialisation happened miles before the resource is bound to the variable. As long as it is bound ASAP after it's been acquired in order to avoid the case mentioned above.
Hence, it'd be better called DIRR. Destruction Is Resource Release. Or RRID.
You know what? Let's try to popularise those names. 😆
@@Ceelvain In rust it definitely doesn't matter whether the value is bound or not to whether there is a gap in which a panic (aka exception) can cause a memory leak. There is no gap, when these things are lowered to the low level intermediate language all temporaries have bindings and drop elaboration happens at this level. All possible code paths are covered, including the panicking ones.
After learning Rust, my best advice is to write it without using borrows at first. Do a lot of copying and returning new objects. It is not efficient but it trained my brain to think about the memory allocation and moving process. Then borrows felt like a natural optimization.
C++ nitpick: you can't have a function ~Foo in a class named Bob. The destructor has to be named ~Bob, and similarly for the constructor.
So Bob has a constructor called Foo? And the scalar delete operator is used in the destructor to delete the array allocated with operatot new[]? And b gets automagically renamed to bob in Rust? I guess we are dealing with a computer scientist here.
Nah, just your average Rust evangelist.😝
2:37 This is NOT the same as in other languages. Val in Kotlin, final in Java, etc. makes the variable itself not reassignable not immutable.
final var person = Person(19);
person.setAge(20);
does mutate the variable even if it has final. In Rust, however, you cannot* mutate the variable at all (as for age_set(u16) you would need a mutable reference).
(* ignoring concepts like internal mutability using RefCell (assures the 1 mut xor n imut rule at runtime instead of compile time), unsafe and such)
awesome video! there are so many interesting things in rust! hopefully we get more Rust content
What I've realized by studying different programming languages for around 5 years is that the harder the language, the better "programmer" it makes you in the long run, I think a lot of people can code using a language like python or JavaScript, but very few could even begin to understand the many rules and regulations of low level languages.
Unless you're absolutely stubborn about learning a low level language, you won't be able to cope with it
Am i the only one watching this, finding it super interesting every single upload yet understanding about 5% of what they tell u?
Class name is Bob and constructor/destructor name is Foo.
This is something new added to C++ by Ian !!!
ˇ2:45 : Well, C and Java also have construct to declare something to be a constant. All Rust does is make "constantness" the default, and one has to specify mutability ("variability") using an additional keyword.
It's not like other languages are like Fortran V on Univac 1100 series under EXEC8, where even integer literals were actually mutable variables passed to subroutines by reference. Now, _that_ was a source of some really nice puzzles for novices.
Rust doesn’t actually prevent memory leaks. It is fully possible to leak memory in safe rust, although a little harder. This is demonstrated by std::mem::forget, which was at one point unsafe, but after a while it became clear that preventing memory leaks entirely was unpractical in a language like rust, due to e.g. reference counting cycles or deadlocks or tons of different things
6:21 - You have an error. You didn't use the right form of delete. You need to delete arrays differently. In this case, it probably will be just fine.
Also, you keep saying "C" and then using "C++". They're different languages.
Lastly, the appropriate comparison is not to bare C++ pointers. I hardly ever use those anymore in writing C++ code. The proper comparison is C++'s unique_ptr and shared_ptr. The concept of mutable and non-mutable borrowing doesn't exactly exist with those. But those are the closest equivalent to what Rust is doing.
5:40 you meant 'delete[] this->n;'
in C++ there is difference between 'delete' and 'delete[]'.
GC is the single worst cause of headaches in my job. I'm a senior programmer who works on video games, and I mostly deal with low level optimizations. An unreal GC collect call is going to cost 125ms on a switch. This is just for a call to GC.Collect, there might not even be any garbage to collect. Yes. that's 10 frames at 60 fps spent just looking for things to free. RAII amortizes these costs so they are hit at the moment they are freed. Spreading it out.
Okay, but it's not C++. No one writing programs like that in real life.
There are tools which will help you to find different kinds of errors.
Clang-tidy, Valgrind, PVS Studio, compiler flags like `-fsanitize=address`, maybe something for MSVC from Microsoft.
Clang-tidy, can analyze code in real time, it's easy to use, and built in in CLion IDE, can be easy installed in Vim/Emacs with a help of LSP and clang tools.
And of course there are unique pointers and move-semantics since 2011. Rust is cool, but C++ does not stand still.
Waited for a quite a while to hear "Rust isn't a niche language". Also it has name for it's memory management system - OBRM (Object Based Resource Management)
Writing C-with-classes and calling it C++ (in that you didn't use std::vector, which is the proper approach to this code) is a bit of a hatchet job. What Rust has "built into the language" is literally right there in C++ just the same.
I know examples are usually contrived but like damn dude.
Nice to see y'all covering Rust
9:20 I would actually say the inverse here: at best the program crashes, at worst it gets some garbage. In my experience, debugging with garbage data has been much more hellish than immediately getting a seg fault and knowing the exact location of the problem.
Why do you intentionally write bad code in C++ to elevate Rust? I'm sure the Rust community doesn't want you doing that.
Right. C++ solves this problem with std::unique_ptr.
The code is bad, but it's also more code than necessary. He had to go out of his way to make an issue, whereas one std::vector would have solved the problem.
I think you're forgetting the audience this video is for. A lot of people watching this don't know about rust, c++, or memory management, and they aren't going to be coding embedded code any time soon. He just needed to demonstrate clearly and quickly the memory management problems that Rust's ownership model is trying to solve. This isn't a sales pitch for programmers, it's educational content for laypeople.
It's really easy for a new programmer that doesn't know about smart pointers to fall for those traps. If he wanted to make that point he probably should had used C.
Rust is better than C++ for other reasons so you're right, no need to write bad C++
The point is also that you *can* write memory unsafe C++, despite following rules like RAII, whereas you can't in Rust, unless if you write "unsafe" somewhere.
He could've presented an automatic code analysis tool for C++ that implements the move/borrow semantics and gotten to the same result, but rust has that tool built in and a syntax that is built around the move/borrow semantic, so why not use that instead.
I spotted a mistake in his code. The constructor and destructor should have the same name as the class name. Here name of class is Bob and you named the constructor and destructor as Foo
I could hear all the rust users screaming when he asked, "oh it's made a copy?"
Thank you for sharing this excellent video! I truly appreciate the effort put in by education professionals like you to create such valuable content.
Cool that you made a video about Rust!
Did anyone else notice that Bob's constructor and destructor had a different name
Yay a video on Rust!
When you have a class Bob in C++, the constructor is named Bob(arguments) & the destructor is named ~Bob(). The code shown in the video can't compile.
6:00 this is Undefined Behavior btw, you are not allowed to call delete on a pointer allocated using new[]
Correct way to free it would be delete[] this->n;
Great content, but a bit hard to follow. All the func_n examples introduce unneccesary cognitive load here. Also it would be great if it was being presented with live compiler messages. Showing exactly what the Rust compiler would be telling us if we were using an IDE.
This video is way below Computerphile standards. In your series the presenter dives so smoothly into the foundations of the matter and explains the core logic behind for total n00bs. All I understood from this video is how cool Rust is because it's the same as C++, but opposite. There must be a reason it's so popular, but the video failed to convey it.
RAII is not only malloc and free. RAII is also about file streams, memory streams, file handles, network sockets, db connections.
Mother of Code. For all my love of Rust...
* Foo() is not a constructor for class Bob... Surprise...
* In C++ there's a **strict** difference between "delete x;" and "delete[] x;". You used the wrong one.
* Hardly anyone writing a fresh codebase with sufficiently modern C++ would use field "int*" when they can use "std::vector".
EDIT:
And of course, in Rust you can have a block of memory that has no owner. That's what bare pointers are for. That's unsafe{} but possible.
6:30 no, you don't have to write that urself, that's where stl comes in: we have generic containers, like std::vector for storing generic data, std::string is a text container and std::unique_ptr\std::shared_ptr are RAII wrappers, that do basically the exact thing you've shown: it would allocate an object for you, keep track of the memory and delete it, when the object(or all of the objects, that point to the resource) goes out of scope.
he's also doing it wrong. He's meant to delete[] because he allocated a sector of memory, not a single element. In most unix systems and linux distros that is not a problem because the allocator used works just fine either way, as it simply writes how much memory has been stored using a size_t chunk of memory just before the first element. But in the case of windows for example, that is not the case, the allocators are different, and many other systems could be using a different allocator, so using a delete there is UB. More evidence that we should not blindly trust all the things we're told by people on the internet.
You should also take a look at Zig.
I thought RAII was different from rusts ownership model.
Those are separate concept which often mesh together.
I like how by 4 minutes in I already picked up something interesting from this.
I think something that was a little left out ist that you can do most things with rusts RAII principles (except for multiple owners, so reference counting). If you want to free some memory halfway through an objects lifetime, you can give the Memory to an `Option` which does runtime checks on the variables validity, which your Object then holds onto. This then forces users of the object to consider whether or not the memory is valid at that current time. In rust you very rarely actually need `unsafe` blocks, unless you're doing something like embedded programming or unsafe magic.
Also rusts reference counting doesn't actually violate the one owner principal, since the reference counted "backend" owns the original data (in implementation this isn't quite correct, there is an UnsafeCell backing all of this, but for the users purpose this doesn't matter)
madlad uses relative line numbers
10:40 Semantically Vec isn't really the same as the example in C++. Box would be more fitting.
the problem with garbage collection is much more then its cost in resources.
It doesn't solve the general problem of resource management and in/out operations.
because with garbage collection the time and ordering of destruction is not unspecified.
so any resource that has side-effects in its destructor is usually not safe to run during destruction.
RAII and rust's Drop traits solve this issue by having a per-determined ordering of destruction.
so RAII is used in C++ for many many things:
management of memory, lock/unlock mutexes, timing scopes, management of OS/external handles,
unhandeled error detection, parser scope tracking, statistics tracking,
post-condition checking.........
also this video makes it sound like RAII must always be done by hand in C++ which is wrong.
Most of the time libraries have the utilities with the behavior you need an you can reuse them.
rust's Box should be compared with std::unique_ptr. not doing it by hand.
C++ arrays should be deleted with `delete[]` operator @ 6:04 , this is because over-allocation or an associative array technique is used to hold the number of elements in array, so you need to hint the compiler to de-allocate the latter too.
9:20 at best you crash and at worst you get garbage, not the other way around.
More rust content I love it a lot
Can you please share the NeoVIM configuration used by Ian in the video?
java and c# devs will argue about design patterns and their own personal dogma on the only "right" way to code until the cows come home. C++ devs only say 4 letters, RAII.
The C++ code given as an example here compiles fine (change the name "Foo" for "Bob"). It shows clearly that you can mess up things easily in C++ and other traditional languages. I know that there are now better ways of writing this code in modern C++ to avoid pitfalls, but the point here is to show how safety tightly bound into the language itself can address these quirks, but I admit a better programmer can do as well ...
if you do a new[] please do a delete[]. Even in a so simple example bug has creep in. Furthers proof that most programmers should not write this kind of code themself.
It's pretty basic stuff that any half decent programmer should get right. It bugs me when people blame such things on the language. Like blaming a car for driving the wrong way down a one-way street.
I don't know any rust. Isnt the ownership principle the equivalent of using std::move on a unique pointer in c++ only here it's the default pointer behavior?
ownership in rust is quite tightly linked with lifetimes, which (as far as i know?) c++ has no equivalent t
Rust moves are destructive moves, whereas C++ has to leave the moved-from object in a valid state even if it's not used again.
The differences are: Moves are the default, deep copies (called clones) are the explicit alternative. Also moves are "destructive" where the compiler doesn't let you access the variable anymore. In C++ moves put the object into a "valid but unspecified" state, which is a little bit odd for types that don't necessarily have such a concept. Like what's a valid but moved mutex, thread, file, tcp stream, etc? For a lot of types there's an equivalent of a null value, but for those that I mentioned the classes need to do some special "bool is_moved" or so and probably throw an exception on all the methods? It's really weird.
C++ unique_ptr and shared_ptr are just like Box Arc in Rust.
Do not forget the RAII doesn't help the heavy lifting of resource ownership juggling. In non-GC realms the language users still have a burden of ownership management to think of, one way or another, whereas the GC does it all.
Wouldn't you just use a unique_ptr in the c++ example and do essentially all the same thing?
unique_ptr is called unique for a reason. He would've had to create a (deep and expensive) copy of the vector to resolve the problem if he used unique_ptr (or vector). The solution would've been shared_ptr, but even that has a runtime cost, whereas in Rust it would've just been a completely free borrow and no unique_ptr / shared_ptr at all.
You can create a std::unique_ptr and move it around to pass ownership or pass it by reference to allow borrowing of it. Its the point of unique_ptr. Its what it does.
@@Guru4hire Yeah but that misses the point of the example in the video. The example was that Bob had ownership and got destroyed and there was a dangling reference to the numbers still. unique_ptr wouldn‘t have helped here at all, unless you would‘ve moved out the numbers, but that‘s not what he wanted to do, he wanted to destruct Bob.
I think I understand the point of disagreement now. I am saying that a unique_ptr to a class or struct bob which has a public unique_ptr to a vector of ints performs essentially the same as all the rust code examples. I would argue that the pathological get_n function (which is not in the rust example) in the c++ example would fail to compile as the unique_ptr's copy constructor is deleted. I would have liked to see how Rust handles the contrived use after free bug with the get_n function.
@@Guru4hire one other thing is that C++ unique and shared is a runtime cost where Rust is a compile time check.
C++ compiles down to pointers allocations and checks where rust just compiles to pointers.
5:50 Shouldn't it be
delete[] this->n;
missing the array.
Thanks for the video. It would be nicer, if there were some program runs as well, like the garbage collection video :)
Exactly the time when the comments section is noticeably better than the video itself
Class Bob but constructor and destructor Foo?
In C++, aren't constructors and destructors required to have the same name as the class?
5:46 should probably use delete[].
Yikes. At 4:53... The constructor should be called "Bob" since the class is "Bob". Also, you shouldn't use "this->n". It should be Bob(int x) : n(new int[x]) {}
Further yikes. At 5:45, the destructor doesn't use the correct delete operator, it should be "delete[] this->n"
great feature, i wish rust had Java like readable syntax, mimicking C was definitely a mistake. C syntax is horrible but probably devs comes from C background.
I was here before ThePrimeagen's reaction
With more than 2 million subscribers, I hope you can get a tripod soon.
My man went to Mike Pound's wardrobe and absolutely raided it
This is 1998 C++ ... 😕
One of the things I have never understood about rust is how to do something like a read write queue. There are many cases were we pass immutable as a way to create "Read-only" memory for a part of the program but not that its immutable. By this logic, we can easily make a concurrency queue and pass it to all the workers, but any attempts add any jobs will then be stopped as you would be mutating a queue which has borrowed references.
The thing you are missing is that the mutable vs immutable reference in Rust is a misnomer. What they actually are is unique vs shared reference. It is possible to create types that can be mutated through a shared reference. A prime example of this is mutex.
You had me at "It definitely wants to borrow from..."
It would be nice if the code actually compiled (C++ class Bob having constructor and destructor named Foo: no) or does what we're told it is supposed to do ( in rust Vec::new() doesn't allocate anything. It creates an empty vec - such a vec starts allocating in push).