> Back to the major topic: For "better FP" to emerge inside Nim you need more > restrictions to the mutability aspects but the solution IMHO is not "more > immutability", it's "single owner mutability". Immutability simply throws > away too many good things, I cannot imagine what an "immutable" lock or queue > or channel would look like... ;-)
We shouldn't conflate FP with the immutable, persistent data structures that @sschwarzer mentioned. The latter would be very useful even when writing typical imperative Nim code. The [hashed array mapped trie](https://en.wikipedia.org/wiki/Hash_array_mapped_trie) (invented by Phil Bagwell, and the first immutable variant was created by Rich Hickey for Clojure) has performance characteristics you can't get with mutable data structures. RRB trees (also invented by Bagwell and [implemented in Clojure](https://github.com/clojure/core.rrb-vector)) improve upon it even more. Really exciting research and very useful even without FP. For example, in my rules engine, there are a few places i have to defensively make local copies of seqs before mutating them; if i was using a persistent vector, making a "copy" would just be a constant-time operation, no need to make a full copy in memory due to structural sharing. Whenever i find the time, i want to make a Nim variant just for this use case. I suspect it'll be a huge perf win, even if consumers of my library never use persistent data structures themselves.
