> I'm not that familiar with Rust but, as far as I can see, it makes sense to say that Rust's borrow checker is an interface to a O(1) garbage collector (as fast as no GC at all), that the programmer has to implement at compile-time for all values. All the borrow checker-code is compiled into a no-runtime-overhead garbage collector, that is embedded into the resulting generated code.
Not really : the borrow checker is just a compile-time analysis tool which checks that you respect some conventions with pointers :
- each value has only one owner
- each pointer to a value must leave less time than the target value
- you must only have one mutable pointer to a value
- you can have as many immutable pointer to a value as you want as long as there is no mutable pointer to the same value (think of a statically-checked version of a RW-lock)
The borrow-checker isn't responsible for freeing memory at all. Freeing memory is done by RAII like in C++, but the conventions enforced by the borrow checker ensure that the deallocation of memory is safe.
The problem I was hinting is that it looks simple on paper and when following the book exercises, but then one picks up a random GUI library, needs to map callbacks and event handlers, it starts to get a bit harder to understand if one needs a lifetime annotation (which one), (A)Rc, RefCell, and starts to jungle them around until it compiles.
Again, maybe it is just me and need to spend more time learning it.
You're right, that's the difficult part about Rust. Every novice has to go through these hoops to acquire the intuition. I'm midway through and feel comfortable working with Rusty libraries, but interfacing with C libraries that widely employ shared state is a major pain. Fortunately, more and more libraries get rewritten in Rust or acquire sane Rust wrappers.
> Again, maybe it is just me and need to spend more time learning it.
I had the exact same experience : after my first reading of the Rust book, I though I understood what's going on but once I tried to actually write something I was totally lost. I stopped using Rust for several months and when I came back, I read the book again and this time I had no troubles writing stuff and the concepts of ownership and lifetime became really clear.
I think the concepts behind the borrow-checker are really straightforward[] once you've internalized them, yet they are really unintuitive to the beginner. It's quite paradoxical.
Not really : the borrow checker is just a compile-time analysis tool which checks that you respect some conventions with pointers :
- each value has only one owner
- each pointer to a value must leave less time than the target value
- you must only have one mutable pointer to a value
- you can have as many immutable pointer to a value as you want as long as there is no mutable pointer to the same value (think of a statically-checked version of a RW-lock)
The borrow-checker isn't responsible for freeing memory at all. Freeing memory is done by RAII like in C++, but the conventions enforced by the borrow checker ensure that the deallocation of memory is safe.