I think promoting Rc and Gc in that way is a little disingenuous, since memory safety permeates the whole design, meaning that you can never just throw memory and mutability around without caring like you can in other languages.
They help solve ownership "problems" but can't paper over the interesting part of Rust: lifetimes and memory safety. (i.e. they stop you having to structure everything as a strictly owned tree, allowing DAGs (with plain Rc) and arbitrary graphs (with Gc and Rc + weak pointers).)
However, unique ownership will always be the thing that's easiest for humans, and more importantly, the compiler to reason about, and so shared data will always be slightly harder to work with than non-shared data.
> I think promoting Rc and Gc in that way is a little disingenuous, since memory safety permeates the whole design, meaning that you can never just throw memory and mutability around without caring like you can in other languages.
I'm not sure why it's disingenuous, Rc and Gc are supposed to be memory safe as well, and as you note their point is simply to not bother with ownership.
> However, unique ownership will always be the thing that's easiest for humans, and more importantly, the compiler to reason about, and so shared data will always be slightly harder to work with than non-shared data.
Which, generally speaking, I'd say is an advantage not a drawback.
I just mean saying "Rust has manual memory management but there's Rc and Gc to save you from that" isn't quite true: the hard part of "memory management" in Rust is convincing the compiler that your lifetimes work out (i.e. it's not doing it correctly that's hard, it's getting the compiler to verify what you've done is correct that's hard), and Rc and Gc don't really help with that, except if you use them everywhere (and the stdlib purposely doesn't use them everywhere, so you will hit lifetimes at some point in your codebase).
> Which, generally speaking, I'd say is an advantage not a drawback.
Of course, but being an advantage doesn't change the fact that Rc/Gc are not a solve-all-your-memory-management-issues tool in Rust.
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.
I'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.
If 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.
They help solve ownership "problems" but can't paper over the interesting part of Rust: lifetimes and memory safety. (i.e. they stop you having to structure everything as a strictly owned tree, allowing DAGs (with plain Rc) and arbitrary graphs (with Gc and Rc + weak pointers).)
However, unique ownership will always be the thing that's easiest for humans, and more importantly, the compiler to reason about, and so shared data will always be slightly harder to work with than non-shared data.