Hacker News Reader

Comment by skariel123 | Hacker News Reader

mutating in Rust is not like mutating in JS, Python, Java C# or many other languages. Rust tracks ownership, you always know who might mutate the object and when. It is a very unique experience programming Rust

View on HN

This might be more sane in Rust, I am not familiar with Rust.

I have used a lot of redux in js and written a few things in Elm, and the immutible property of application state is very central in both, and an important part of being able to reason with the ui, as well as events happening concurrently.

Immutability and ownership arent unrelated. They solve the same problem.

The problem with shared mutable state might appear to be then “mutable” but it’s the combination of shared+mutable.

Ownership removes one (if it’s mutable it’s not shared). Immutability removes the other.

The outcome is the same: you can reason about your code, including concurrent code.

The price of ownership is some extra mental overhead. The price of immutability is some extra copying and cumbersome updates.

In JS/Elm you have no choice but to manage shared mutable state using pure functions and immutable data. In rust you can use either model.

In rust you can use either model.

Not really. Of course you can copy immutable data upon update, but persistent data structures (large shared state between data versions)[1] are hard to write without GC...

[1] https://en.m.wikipedia.org/wiki/Persistent_data_structure

If you don't have cycles, ref counting can work (it's a kind of GC after all), but it indeed comes with a big performance overhead compared to a modern GC.

Reference counting [1] and atomic reference counting [2] are supported within Rust, and are sufficient for any persistent data structure without cycles. There's also a prototype crate for a mark and sweep GC [3], which would likely work for anything else. Writing such data structures using these features might be a bit more tedious than writing them in a GC language, but I suspect the increased explicitness provides a worthwhile tradeoff. See the crossbeam library [4] for some examples of lockless concurrent data structures implemented in Rust.

[1] https://doc.rust-lang.org/std/rc/struct.Rc.html [2] https://doc.rust-lang.org/std/sync/struct.Arc.html [3] https://manishearth.github.io/blog/2016/08/18/gc-support-in-... [4] https://github.com/crossbeam-rs/crossbeam

As an alternative GC in Rust, you also have Josephine[1], which uses the SpiderMonkey[2] GC. It's cumbersome to use though[3] and should probably not be used outside of Servo.

[1]: https://github.com/asajeffrey/josephine

[2]: mozilla's JS VM

[3]: this is how you call a doubly linked list managed by the JS GC https://github.com/asajeffrey/josephine/blob/master/examples...

I’d say it’s not the immutability that’s so valuable, rather than restricting where it can be done. If the app state can only be mutated in one place in your app and under strict conditions, formal immutability no longer offers that much.

"You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

The problem is that the banana has a jungle attribute. If you pass a bannana to a function you're also implicitly passing in the entire jungle. The function could mutate the entire jungle without your knowledge. If you remove the jungle attribute from the bannana class you have to explicitly pass the jungle as a function parameter. This makes it far easier to understand the code.

The same applies to return values. If you return every changed value from a function and then explicitly handle the change at the callsite it doesn't actually matter if the data is mutable or immutable because the side effects are visible and easy to understand.

Reply on news.ycombinator.com