4 ms·
>Why Immutable Data Structures >... Rust, being what it is, does a good job of discouraging this kind of behaviour, and keeping it strictly controlled when it'
by Groxx 9y ago
>Why Immutable Data Structures
>... Rust, being what it is, does a good job of discouraging this kind of behaviour, and keeping it strictly controlled when it's necessary, but the standard library doesn't provide collection data structures which are optimised for immutable operations. This means, for instance, that if you want to add an item to a Vec without modifying it in place, you first need to clone the whole thing before making your change.
>Data structures exist which are designed to be able to make these copies much cheaper, usually by sharing structure between them, which, because this structure is also immutable, is both cheap and safe. ...
Seems pretty straightforward. You'll still have some benefits to immutable-data coding-patterns because it requires only read access on a value, not write, all the way up to the moment you want to swap values (if ever). Making that faster is a worthwhile goal.
- taeric 9y agoSeems misguided, though. Specifically, this has the implicit claim that the shared structures will be faster than the alternative. The whole "is both cheap and safe." However, Rust uses other mechanisms to provide the safety, such that it may be "cheaper," but only compared to copying the full data structure. It will not be cheaper than just modifying in place. The question, then, is how often is that strategy truly idiomatic and a net win in Rust?
- steveklabnik 9y agoWe had a talk at RustConf previously about the Xi editor; it uses an immutable data structure to handle text. It's a video but the author lays out the details here: https://www.youtube.com/watch?v=SKtQgFBRUvQ https://www.youtube.com/watch?v=SKtQgFBRUvQ They make an interesting argument about how Rust makes it easier and nicer to write these kinds of structures. It's still an area of exploration in Rust generally though; I wouldn't say immutable data structures are idiomatic, but that's also just because we haven't had a ton of easy ones to use, so nobody uses them. So we'll see!
- taeric 9y agoI saw downthread a link to someone talking about how you can already treat the standard collections as values. Has a good argument for how it can be beneficial to keep the same interface regardless. Has a good concession that there are definitely use cases where persistent collections make sense. I'd imagine they are not as common as one could expect. (I grant they are also likely more common than I expect. :) )
- raphlinus 9y agoThanks for the shout-out. You can also read the docs[0] about the rope data structure (the release is a bit old, if you're really curious git master is better). I admit this is a fairly specialized use case, for most things xi uses mutability in a controlled way. [0] https://docs.rs/xi-rope/0.2.0/xi_rope/tree/index.html https://docs.rs/xi-rope/0.2.0/xi_rope/tree/index.html
- cryptonector 9y agoWith an immutable data structure the only synchronization cost is that of atomic reference count increment/decrement, but it feels like you're mutating shared objects, so the API is very easy to use. For an example API I'm familiar with, see https://github.com/stedolan/jq/wiki/C-API:-jv https://github.com/stedolan/jq/wiki/C-API:-jv
- winstonewert 9y agoOk, but I repeat: what is the use case? Yes, this allows me to do things like add an item to a Vec without modifying it in place, but why would I want to do that? What's the situation where that's helpful? In other languages I do that, specifically to avoid mutability hell, but that doesn't apply to rust. EDIT: Thanks to the responders for the great examples!
- masklinn 9y ago> Yes, this allows me to do things like add an item to a Vec without modifying it in place, but why would I want to do that? What's the situation where that's helpful? The context is obviously shared concurrency (hence the library using Arc period), so you can cheaply get a shared immutable structure and manipulate it on your side (without sharing it back), and if necessary share/swap it in at some point, they provide cheap read/copy/update cycles. With regular collections Rust would preclude misuses but that would still require either deep copies upfront or fairly large exclusive critical sections.
- the8472 9y agoIt might be useful for RCU data structures in multithreaded code
- cryptonector 9y agoAbsolutely. This is one very good use case. Say you have a configuration to read and share with all threads. Each thread can make local changes that will not be visible to the others. The API looks like it's mutating the shared object, but it's actually mutating a copy.
- caconym_ 9y agoOne example: storing a large text buffer in a persistent data structure (e.g. a rope) can allow you to maintain a space-efficient history of "snapshots" simply by keeping pointers to older versions of the buffer.
- Groxx 9y agoNo ability to mutate -> no mutable ownership complications. Ever. And that's probably the biggest pain-point for people using Rust. Not necessary, but can simplify things, by encouraging(/forcing) simpler use of data by default.