It doesn't mean Rust considers leaking memory correct or that it doesn't make it difficult. It means it doesn't force you to prevent APIs like Rc<T> and Arc<T> from allowing people to leak memory in safe code. If it was considered unsafe, those would have to prevent those cycles.
Conversation
Preventing reference cycles would require having very strict type bounds for Rc<T> and Arc<T> to forbid reference counted types nested within reference counted types. Cripples what you can express and would mean you need unsafe code to do something that's type and memory safe.
1
1
The language considering detaching stuff from scope-based ownership with reference cycles, etc. as unsafe also wouldn't prevent you having unbounded memory growth. It'd only prevent doing it in a way that wouldn't be freed as part of returning / unwinding back through main.
1
2
Replying to
A) I don't know enough rust to understand what you said, but
B) there's a fix underway to address this to teach the language that it's unsafe to do this (mentioned in the article) so it can be "made safe".
1
1
Replying to
The article is mixing up the terms undesirable / incorrect with unsafe. The term unsafe in Rust means something specific: type / memory unsafe. Safe Rust doesn't mean bug free or correct code. It simply means code where memory and type unsafety bugs are prevented by the language.
2
1
Replying to
Yeah, problem is many rust people make that same confusion as well.
This seems to make that same confusion:
doc.rust-lang.org/book/ch00-00-i
I couldn't find a proper definition of safe in the rust book. I avoided all the advanced features search results because it shouldn't be there.
1
Replying to
The safe subset of Rust prevents type unsafety, memory unsafety, non-atomic data races, etc. It doesn't disallow splitting off resources from the call stack ownership tree but it makes it very hard to do it by accident. Disallowing it would have been possible, but inconvenient.
2
Replying to
Please get this added to the rust book in a prominent place so that people learning the language can learn where the sharp edges are.
1
1
Replying to
I wouldn't really call this a sharp edge. You can leak memory in Go, Python or Java. The places where it needs to be documented are Rc<T> and Arc<T> which need to explain that strong reference cycles will leak and you should be using Weak<T> to create weak references for cycles.
1
1
The only thing that's a sharper edge than a GC language is that reference counted types will leak cycles instead of a GC coming along to collect them. It's worth noting that until relatively recently, CPython leaked reference cycles if anything in that cycle had a __del__ method.
1
Rc<T> and Arc<T> are a bit harder to use correctly for self-referential types than doing the same thing in a garbage collected language where you don't need to use weak references as often. Weak references are still useful with GC though, particularly weak ref collection types.
For example, if you make a global map in Java for tracking all live objects of a certain type, you're going to be leaking all objects of that type. You need a weak map type like java.util.WeakHashMap so the GC will collect them and the map won't reference them anymore.
1
Rust makes mutable thread local and global variables more painful to use than a language like Java for complex cases requiring references (RefCell/Mutex) which pushes you to do things other ways and therefore reduces opportunities for leaks. Also, not just memory can be leaked.
1
Show replies