The word you were looking for is "immutability".

Such as?

A big one is persistent data structures. Where 'persistent' may not mean what you think it means.

In Clojure it is impossible to surgically modify a data structure. That is, you can't do something like:

(SETF (CAR (CDR x)) 'foo)

which would alter a data structure.

You can modify a data structure, but it returns a new data structure, yet the old one remains if it is not GC'able.

All of the common data structures have this property. Sequences (eg, lists), arrays, maps and sets. If you change the 50 thousandth element of an array, this returns a new array. The old array is unaffected. Yet it gives the performance you expect of an array. (Meaning no apparent cost of copying.)

If you're writing a search procedure, it is trivial to transform one chessboard into a different chessboard, but without concern about the cost of copying (close to zero), or having altered the original value (you haven't). Other variables that have a pointer to that first chessboard don't see any changes.

There are other things such as a great story about concurrency.

Hope that helps.

It should be noted that you can even if you in 99.9% of cases don't want to mutate state.

For the few times when you want to squeeze the last drop of performance, you can use transients[0].

[0] https://clojure.org/reference/transients

How is the cost of copying close to zero or not apparent?

The data structures in Clojure are built on shallow 32-way trees. When you "change" a map or a vector, the algorithm only copies from the root node down to the parent of the leaf you're changing. That's log32(N) copied nodes in a tree of N nodes total.

Because persistent data structures that use structural sharing.

Good answers by others. The cost it not quite zero, but very close. The benefits this buys are huge. The obvious case is recursive search algorithms.

I'll give you another. Laziness. It's built in. It's trivial to create lazy lists that generate their contents as you walk down the list. Even infinite lazy lists. The list of all prime numbers. The list of all fibonacci numbers.

You can use map, which if I remember my CL, is like MAPCAR. But instead of map, you can use pmap which will do the processing on all of your cpu cores.

pmap in CL is one library away, along with preduce, ... (https://lparallel.org/).

Is it lazy?

Of course not, lazy is opt-in in CL, that wouldn't be idiomatic.

Besides, the semi-lazy approach of Clojure's pmap (allocate futures consecutively) doesn't seem to convince everyone:

https://stackoverflow.com/questions/2103599/better-alternati...

https://www.reddit.com/r/Clojure/comments/20lxmv/just_what_i...

On the one hand, when you want to parallelize, you are delegating tasks to workers and you want them to do what they need, independently of you. But on the other hand, laziness introduce a dependency from you, because workers cannot produce a result before they are sure you really need it. This basically slows down parallelization and that's why I am not sure Clojure's pmap is a good general solution.

Note that Clojure Reducers, mentioned here in Zombie Metaphysics (ppmap: http://www.braveclojure.com/zombie-metaphysics) and documented at https://clojure.org/reference/reducers, use strict sequences.

Laziness is great when you need it, but when you don't you shouldn't have to pay for it.

http://clojure.com/blog/2012/05/08/reducers-a-library-and-mo...

Not having separate namespaces for values and functions ;-)