Rust needs back pointers as a primitive. A back pointer and a forward pointer are locked in an invariant relationship (A points to B which points back to A). The borrow checker needs to know about that to check back pointers properly. Then you could do trees, doubly-linked lists, and various other graphs safely.<p>(The two basic constructs that are hard to express safely in Rust are back pointers and partially initialized arrays. There's also some trouble with concurrency primitives. See [1])<p>[1] <a href="https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf" rel="nofollow">https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf</a>
An old school c programmer wants to know if there's a Rust idiom for recovering gracefully from failed allocations (i.e., when malloc returns NULL). Otherwise, what good is a type safe program that crashes due to a heap overflow? If this is the wrong kind of question, I'm listening.
I feel that Rust is something of a religion at this point. Curious how many downvotes I might accrue for expressing that perspective. Might be wrong, but my sense has been that challenges with Rust are written off in an off-hand way and its features exaggerated.<p>Glad to see promising new languages pushing progress forward, though. I'm head high in C/C++/asm for decades so many of the complaints about those languages fall flat with me since I'm over the hurdles via sheer years of experience.
Question: does a hash table with linked-list chaining count as a non-niche use-case for linked lists, or is the linked list just counted as an implementation detail rather than a separate data structure in that context?<p>(Though, Rust's own std::collections::HashMap just does robin-hood hashing instead of separate chaining, and everyone's just going to use that, so "what data structure should a separately-chained hash-table use in Rust" is mostly a moot question.)