In Erlang programs, the amount of data to be copied tends to be rather small. You'd much rather bring the computation to the data than sending the data around f

In Erlang programs, the amount of data to be copied tends to be rather small. You'd much rather bring the computation to the data than sending the data around for computation. If you are storing a lot of data, you either tend to keep it in ETS, which has its own storage engine (and you copy the small parts of data you work on in/out of the ETS system), or as binary data, which are tracked by an ARC-like system in its own arena/heap. Of course, if you systematically abuse the system and ask it to copy several megabytes around all the time, your efficiency will suffer. But note that this is bad form: yes, it is faster locally internally inside a given node, but once you start running true distribution, you don't want to copy megabytes of data between nodes anyway. Shared memory tend to imply a lot of locks, which can bring a lot of contention as well. It is far more complex than just a general rule which says "copying is always bad". And this was my main point, more or less. It is a mistake to see copying for all its bad behaviour, without ever wondering what it brings to the table as a result.