I can grasp Haskell without major issues, follow C++14 and C++17 meta-programming tricks, yet I still don't understand quite well how to deal with the borrow checker on Rust.
Still haven't given up on it, but it shows the learning curve is a bit high, or then it is me that cannot wrap my head around it.
In the world of Haskell, the -> arrow embeds a GC (with runtime overhead) into the genrated code. A similar interface to Rust's borrow checker in Haskell (no runtime overhead) would be the ⊸ arrow from LinearTypes (in a future where GHC's GC is able to take advantage of this).
It looks, to me, like the arrow (⊸) notation is a lot simpler inteface to a no-runtime-overhead garbage collector -- or the absense of a traditional GC, in other words -- than Rust's borrow checker. But I'm looking forward to seeing how it plays out (it will probably take years before it becomes reality).
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.
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.
[] except when the borrowck is not yet smart enough : http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-...
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 [...]
[1] https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...
Rust will never be more than an occasional coding exercise for me personally, because doesn't fit the type of work I do (Java/.NET/UWP/Web/Android) where project tooling is dictated by customer IT.
However coding exercises in whatever language X helps to open our mind to new ways of solving problems, that we can eventually use in our daily tools.
When I give these statements my goal isn't to bash the language, rather give another point of view that might help understanding which areas the design team should focus, or not.
After all it is their final call and they need to pay attention to those that are actually using it in production and their real problems, not random dudes like me.