3 ms·
I think you're in violent agreement with masklinn. His point is your point: it is possible to avoid memory lifetime issues by using garbage collection, but that
by scott_s 13y ago
I think you're in violent agreement with masklinn. His point is your point: it is possible to avoid memory lifetime issues by using garbage collection, but that is not idiomatic Rust, and the design of the language encourages you to reason about memory lifetimes.
- masklinn 13y ago(note that dbaupp is a core rust developer[0], if he disagrees with my statements I'm probably missing something somewhere) [0] https://github.com/mozilla/rust/commits?author=huonw https://github.com/mozilla/rust/commits?author=huonw
- dbaupp 13y agoI'm not disagreeing with them, yes, but I do think people tout Rust's Rc and Gc (the latter og which doesn't even exist properly yet...) as overly optimistic solutions to escape Rust's variation of "manual" memory management: they don't entirely free you from the shackles of the borrow checker, and even introduce worse lifetime issues (failure at runtime as soon as (certain types of) mutability is required). That said, the lifetime system make it hard to get things dangerously wrong, so I'm quite happy with the tradeoff Rust offers.
- pcwalton 13y agoIf you use RC and RefCell properly, there shouldn't be dynamic borrow failures any more than there are ConcurrentModificationExceptions in Java or NSEnumeration failures in Objective-C. Sadly most people don't use them very effectively; it seems more work is required to make the right patterns more obvious and easy to use.
- dbaupp 13y agoOf course, if one uses things right then stuff works fine... It's relying on people to do things right that's tricky (which is why we have Rust). My point was mainly that you lose much of the compiler's assistance by moving from singly- to multiply-owned data.