> This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. The JS world has this in Immuta

> This sort of concern would be addressed by the library ecosystem rather than "the language", which might not be for everyone. The JS world has this in Immutable.js, which provides a set of persistent data structures that are excellent by any measure. However, since it's not the default data structures provided by the language, practically no third party library actually consumes/emits them as input/output directly. What this means in practice is that most of the performance benefits of structural sharing through Immutable.js ends up being outright negated many-times fold by the necessity to recursively convert to and from JS native collections at the edges of your system that inevitably needs to call out to/consume data from third party libraries. Not to mention that the developer ergonomics of working with Immutable.js pales in comparison with that of native JS collections, since you're limited to the traversal and manipulation APIs provided by the library, and have to forgo excellent functional utility libraries like Ramda [1], and handy language features like destructuring and spread. This is why even in systems that embrace immutability like Redux, the prospect of using Immutable.js comes with a huge list of caveats that are well documented [2], driving most developers to end up choosing JS native collections and doing naive copy-on-write without structural sharing across the board. [1] http://ramdajs.com/ http://ramdajs.com/ [2] http://redux.js.org/docs/recipes/UsingImmutableJS.html http://redux.js.org/docs/recipes/UsingImmutableJS.html In contrast, in the ClojureScript ecosystem, everything uses the default persistent collections, and so this is never a problem.