Conversation

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
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
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
Replying to and
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
Replying to and
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.
1
Replying to and
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
Replying to and
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
Replying to and
It's dramatically harder to end up leaking resources other than memory in Rust compared to Go, Java, Python, etc. because of automatic destructors vs. manual defer / try-with-resources / with statements. Rust is far better at avoiding all kinds of non-memory resource leaks.
1
Replying to and
Just clarifying I won't do twitter.com/encthenet/stat. It's not a slight against the people who work on it now but out of principle I won't contribute to it based on what happened before. Maybe if certain people weren't still heavily involved in the community I wouldn't avoid it.
Quote Tweet
Replying to @DanielMicay
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