Comment by runeks | Hacker News Reader

Comment by runeks | Hacker News Reader

Parent Full thread

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.

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).

> 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.

[] 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

It is often best to not comment on things you don't understand.

    but, as far as I can see,

Ah you'll power though anyways!

    it makes sense to say that Rust's borrow checker is an
    interface to a O(1) garbage collector [...]

You aren't _that_ far off in terms of CS fundamentals there is a lot of theory you are missing. Rust's _GC_ is called RAII [1] it is used by C++ as well. Effectively the compiler traces the lifetime of an object and inserts a drop/free/destructor call when it leaves scope.

[1] https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...

It would have been more clear for me to have said: "for the purpose of discussion, let's view Rust's borrow checker as an interface to a O(1) garbage collector [..]".

Reply on news.ycombinator.com