?? Now I have to come to the defense of Rust - it does prevent memory leaks (but not space leaks where you leak memory, but it's all being referenced from somewhere). The borrow checker should also prevent race conditions (as not doing so would violate the aliasing rule)

This is all provided we stay in safe Rust land, and don't do concurrency or call external APIs, but that's not a claim I'm holding against the language.

This isn't the point I'm making - the issue I have is that the Rust borrow checker is not powerful enough to accept most correct programs (of real-world complexity) for various reasons. This does not mean that you can't write complex programs in Rust, it only means that most complex programs which do not have the problems Rust claims to address (successfully), have basically zero chance compiling, unleast they're written the way Rust expects them to.

▲

zozbot234 2 days ago | parent [-]

> Now I have to come to the defense of Rust - it does prevent memory leaks (but not space leaks where you leak memory, but it's all being referenced from somewhere). The borrow checker should also prevent race conditions (as not doing so would violate the aliasing rule)

Rc<> and Arc<> can create true memory leaks where a cycle of Rc<> or Arc<> referencing one another can stay allocated in memory even when all outside references to the objects have disappeared, so the leak cannot even be collected. This is the one thing that is not allowed to occur with a tracing garbage collector as in Fil-C. (Rust also allows leaking memory explicitly, e.g. for the purpose of passing a reference to that memory to foreign code where Rust cannot observe its lifecycle. Then in order to properly drop that memory in Rust, you have to essentially recreate that allocation from scratch.)

Race conditions are a logical error that has nothing to do with the borrow checker. The borrow checker can only prevent properly defined data races, which are entirely unrelated to logical race conditions.

▲

torginus a day ago | parent [-]

You are right, you can absolutely cause memory leaks with Rc, I haven't considered that. However that kind of raises an interesting point - Rc<T>::clone clearly mutates something under the hood as the reference counter is shared, however its not mut. Having something in the core language that breaks the rules and causes actual problems in practice is kind of an ill omen.

And I meant data races, I have stated in my previous post, that race conditions due to issues existing outside of the language, like external libraries or network requests are not the fault of Rust. Neither are logic mistakes a programmer makes.

	▲	zozbot234 a day ago \| parent [-]
		Interior mutability is explicitly provided for in the language, and consistently marked under the hood via UnsafeCell<>. Thus, the compiler can always check whether interior mutability is possible, including wrt. reference counts. In practice, the &mut modifier has more to do with the absence of aliasing (much like *restrict in C) than mutability itself.