3 ms·

This list may paint Rust as a weird language that can't do anything (not even a linked list!?), but it is a good advice. Rust is easy when you do things "the R

by pornel 5y ago

This list may paint Rust as a weird language that can't do anything (not even a linked list!?), but it is a good advice. Rust is easy when you do things "the Rust way" (with more overly-cautious thread-safety, immutability, and tree-shaped data than you may like). You can protest and insist that you do things your way, or you can learn the language. You first have to learn the language as it is, to understand it can and can't do, so you don't get stuck trying to force a solution that it just won't allow. As for linked lists and graph data — Rust can do it. The problem is people try to use references for them, and that can't work. Rust references are not general-purpose pointers. I find the naming very unfortunate, because it sounds too close to holding objects "by reference" in other languages, but Rust references can't store data! Rust references semantically closer to being mutexes evaluated at compile-time. Your first attempts at a linked list out of circularly dependent mutexes is going to be total nonsense.

ncmncm 5y ago
Graph data structures are almost always better represented as some sort of array, with indices for links, than as loose objects on the heap connected with pointers. (This is true in any language except Lisp.) Often the links should themselves be entries in another array, and not just indices, because in the real world you probably want to be able to annotate the links, too. Sometimes only the links. Heap-allocated graph nodes are really only for CS classes. At the opposite extremum, use an NxN bit map, with a 1 at a[n,m] to indicate a link between n and m. Or a regular NxN array, with a value V indicating a weight between n and m. Again, no pointers.
chalcolithic 5y ago
>Rust references semantically closer to being mutexes evaluated at compile-time This is brilliant. Do you have a blog(or anything that comes close to it) about Rust?
- dystroy 5y ago
  This is indeed interesting. I usually start to explain "mut" as meaning "exclusive", and I hadn't seen the now obvious relation with "mutex". "mut is for mutex".
- Measter 5y ago
  I've been thinking along similar lines for a little while. For me, it's not about mutation, but unrestricted mutation. When a unique reference (&mut T) exists then the only possible way to even look at the data is through that unique reference. In that situation, there's no reason to have any restrictions on mutation, because nothing else can observe it. With shared references (&T), multiple parts of the program can access the data at the same time. If you mutate in that situation you can end up with memory corruption due to data races, so mutation has to be restricted to require runtime synchronization through RefCells, Mutexs, etc.

by pornel 5y ago

ncmncm 5y ago

Graph data structures are almost always better represented as some sort of array, with indices for links, than as loose objects on the heap connected with pointers. (This is true in any language except Lisp.) Often the links should themselves be entries in another array, and not just indices, because in the real world you probably want to be able to annotate the links, too. Sometimes only the links. Heap-allocated graph nodes are really only for CS classes. At the opposite extremum, use an NxN bit map, with a 1 at a[n,m] to indicate a link between n and m. Or a regular NxN array, with a value V indicating a weight between n and m. Again, no pointers.

chalcolithic 5y ago

>Rust references semantically closer to being mutexes evaluated at compile-time This is brilliant. Do you have a blog(or anything that comes close to it) about Rust?

dystroy 5y ago
This is indeed interesting. I usually start to explain "mut" as meaning "exclusive", and I hadn't seen the now obvious relation with "mutex". "mut is for mutex".
Measter 5y ago
I've been thinking along similar lines for a little while. For me, it's not about mutation, but unrestricted mutation. When a unique reference (&mut T) exists then the only possible way to even look at the data is through that unique reference. In that situation, there's no reason to have any restrictions on mutation, because nothing else can observe it. With shared references (&T), multiple parts of the program can access the data at the same time. If you mutate in that situation you can end up with memory corruption due to data races, so mutation has to be restricted to require runtime synchronization through RefCells, Mutexs, etc.