Hacker News Reader

Comment by steveklabnik | Hacker News Reader

To elaborate on this, nothing about ownership or borrowing has anything directly to do with heap or stack allocation. Allocation fits into the ownership and borrowing rules, not the other way around.

View on HN

Nice. Is it frequently used in contexts outside of allocation? I assume allocation is the primary use, or at least it's the most talked about, but I have never done anything complex in rust.

The most common AFAIK would be when using iterators. An iterator borrows (or mutably borrows, or takes ownership of, depending on how it's called; iter() vs iter_mut() vs into_iter()) the original collection, so the original collection can't be modified while being iterated. This means no "ConcurrentModificationException" or similar (or worse, silent corruption) can happen.

It's used everywhere; it is a pervasive aspect of the language. Every single variable has ownership and/or borrowing properties.

"Linear type systems are the internal language of closed symmetric monoidal categories, much in the same way that simply typed lambda calculus is the language of Cartesian closed categories. More precisely, one may construct functors between the category of linear type systems and the category of closed symmetric monoidal categories." (Wikipedia)

So now the only question is where closed symmetric monoidal categories are applicable :P

One example of where it's used: to enforce correct usage of mutexes. Rust's `Mutex<T>` owns the data it protects. When you lock the Mutex, you get a reference to the data inside it, but it's impossible (a compile-time error) to store a copy of the reference beyond the point where you release the lock.

Cool. So the fifth point is largely nullified, which is a big one -- that the features of Rust would at least be useful in typical safety-critical code.

Reply on news.ycombinator.com