great video! borrow-checking isnt so complicated, especially if youve used RAII in c++ or in general use best practice when working with languages that use pointers for references
Ikr. So many examples of perfectly valid and safe code that won’t even make it past the compiler is ridiculous. And this video short is only the tip of a very nasty iceberg. It’s basically someone else’s power trip fantasy rules about “clean code”, forced down your throat for no real benefit. All these arbitrary rules that are not in the slightest context free, is a disaster waiting to happen when this code needs to be maintained in future.
two facts: 1. there is a real benefit, which is guaranteed memory safety 2. the rules aren't arbitrary I have been extending 5 year old Rust code just fine@@steveoc64
@@steveoc64wow, you are so cool and so edgy for being vulnerable to use-after-frees because the new college intern assigned to work on your 10000+ loc c++ codebase doesnt know how to implement RAII
And btw - rust didn’t invent the ownership model .. that was all done in the 1970s - 1980s. It’s just another form of garbage collection, and those previous attempts never took off either… go figure.
@@thegoldenatlas753 other way around.. you don’t get what “garbage collection” is. You are thinking that mark and sweep is the only garbage collection strategy. The ownership model that Rust uses (taken directly from Simula I) is a form of garbage collection. As is reference counting and RAII. Mark and sweep was invented in the 80s as a more performant method, at a time when the syscall overhead was large.
youre wrong lol rust's ownership model is really similar to RAII, however it has nothing to do with garbage collection, just like RAII has nothing to do with garbage collection garbage collection is the program automatically freeing unused heap allocated values or other unused memory at runtime. rust doesnt do this at runtime, but instead at compile time by automatically inserting destructors after a value goes out of scope, and in order to do this reliably and efficiently, the ownership model has to be enforced by the compiler. this leads to higher performance, as the runtime doesnt have to count references, do mark and sweep, etc., all while ensuring memory safety
@@stompman and those “automatically created” destructors are run at .. runtime. Your comment proves my point anyway. If you were writing something like a web serving app, or a database server, etc, then you can’t benefit from using arena allocators per request, because the borrow checker is dumb, and doesn’t understand the outer context of an arena. Your rust program ends up making a bunch of frees where none is needed (let alone specified in the code). Frees are system calls, and system calls cost time. This is why rust web server apps or db servers will never hit the same performance numbers as C or zig based alternatives. Unless you write the whole thing in unsafe mode, at which point you have lost the battle anyway. It’s even worse when you look at the “automatically generated” wasm output that the rust toolchain spits out, because it assumes you are targeting a traditional PC architecture, and can’t cope with how wasm VMs use memory in a very different way. It’s just not a good fit for systems programming, no matter how much “safety” lipstick you put on the pig
