5 ms·

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 whe

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

kochthesecond 9y ago
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.
- alkonaut 9y ago
  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.
  - szemet 9y ago
    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 https://en.m.wikipedia.org/wiki/Persistent_data_structure
    - littlestymaar 9y ago
      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.
    - smaddox 9y ago
      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 https://doc.rust-lang.org/std/rc/struct.Rc.html [2] https://doc.rust-lang.org/std/sync/struct.Arc.html https://doc.rust-lang.org/std/sync/struct.Arc.html [3] https://manishearth.github.io/blog/2016/08/18/gc-support-in-rust-api-design/ https://manishearth.github.io/blog/2016/08/18/gc-support-in-... [4] https://github.com/crossbeam-rs/crossbeam https://github.com/crossbeam-rs/crossbeam
      - littlestymaar 9y ago
        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 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/dbllist/main.rs https://github.com/asajeffrey/josephine/blob/master/examples...
- zoul 9y ago
  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.
  - imtringued 9y ago
    "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.

kochthesecond 9y ago

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.

alkonaut 9y ago
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.
- szemet 9y ago
  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 https://en.m.wikipedia.org/wiki/Persistent_data_structure
  - littlestymaar 9y ago
    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.
  - smaddox 9y ago
    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 https://doc.rust-lang.org/std/rc/struct.Rc.html [2] https://doc.rust-lang.org/std/sync/struct.Arc.html https://doc.rust-lang.org/std/sync/struct.Arc.html [3] https://manishearth.github.io/blog/2016/08/18/gc-support-in-rust-api-design/ https://manishearth.github.io/blog/2016/08/18/gc-support-in-... [4] https://github.com/crossbeam-rs/crossbeam https://github.com/crossbeam-rs/crossbeam
    - littlestymaar 9y ago
      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 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/dbllist/main.rs https://github.com/asajeffrey/josephine/blob/master/examples...
zoul 9y ago
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.
- imtringued 9y ago
  "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.