2 ms·

The hashed trie structure is definitely more annoying to write without a general garbage collector. Reference counting it works though, and comes with the magic

The hashed trie structure is definitely more annoying to write without a general garbage collector. Reference counting it works though, and comes with the magic trick that a reference count of one means you're the only reference to it, i.e. only one thread can see it, thus mutation is safe. Encoding that in the lifetime rules of rust might be a nuisance. Works very well in C.

kibwen 2y ago
Rust has provisions for safely existing outside of the lifetime rules, which exist largely to accommodate refcounting schemes. You'd likely be using an Arc<RwLock<T>> here. Otherwise you can implement something on your own and express whatever C-style shenanigans you have in mind via the primitives in std::cell or std::sync.
- harrison_clarke 2y ago
  you could do it in rust with Arc<T>.get_mut if you're implementing the clojure data structures, you wouldn't use a cell inside. semantically, they're immutable, and the operations on them all return copies that share nodes with the old one. if you know the old one won't be used, you can cheat and mutate it instead the issue with using Arc for these data structures is that it's a fatter pointer (costs memory, causes cache pressure), and it requires atomics/fences. they also generate a ton of garbage in typical use-cases (unless you can do the mutation optimization). languages with a compacting GC also usually get a faster allocator it's basically ideal conditions for a GC to outperform reference counting
  - kibwen 2y ago
    I don't doubt that a good GC can generally outperform a simple refcounting scheme, but when it comes to the aforementioned count-of-one optimization, Rust already gives you that out of the box by dint of the fact that owned values are moved by default and bumping the refcount is an explicit operation, which means that in any given scope you can simply pass the handle on if you're done with it and subsequent functions can access it without needing to touch the counter at all.
    - harrison_clarke 2y ago
      rust is definitely better than other languages for refcounting, since you don't pay for it on reads

kibwen 2y ago

Rust has provisions for safely existing outside of the lifetime rules, which exist largely to accommodate refcounting schemes. You'd likely be using an Arc<RwLock<T>> here. Otherwise you can implement something on your own and express whatever C-style shenanigans you have in mind via the primitives in std::cell or std::sync.

harrison_clarke 2y ago
you could do it in rust with Arc<T>.get_mut if you're implementing the clojure data structures, you wouldn't use a cell inside. semantically, they're immutable, and the operations on them all return copies that share nodes with the old one. if you know the old one won't be used, you can cheat and mutate it instead the issue with using Arc for these data structures is that it's a fatter pointer (costs memory, causes cache pressure), and it requires atomics/fences. they also generate a ton of garbage in typical use-cases (unless you can do the mutation optimization). languages with a compacting GC also usually get a faster allocator it's basically ideal conditions for a GC to outperform reference counting
- kibwen 2y ago
  I don't doubt that a good GC can generally outperform a simple refcounting scheme, but when it comes to the aforementioned count-of-one optimization, Rust already gives you that out of the box by dint of the fact that owned values are moved by default and bumping the refcount is an explicit operation, which means that in any given scope you can simply pass the handle on if you're done with it and subsequent functions can access it without needing to touch the counter at all.
  - harrison_clarke 2y ago
    rust is definitely better than other languages for refcounting, since you don't pay for it on reads