Everything immutable (every data structure) is a really convenient way of thinking about processing data in the abstract sense. You can think about processing y

Everything immutable (every data structure) is a really convenient way of thinking about processing data in the abstract sense. You can think about processing your (semi) structure data (records) in terms of high level pipelines and processing steps. And, for a whole class of problems this works well. Certainly this abstraction can stretch pretty well. Esp. when your language / framework can optimize immutable data structures under the covers (mutable and reuse.) But the abstraction is just that an abstraction for a mutable platform. The platforms of today (VMs, operating systems, hardware, storage) are not immutable and notoriously full of side effects and undefined behavior. So these immutable language / frameworks end up being good tools at one extreme (high level data processing), bad at the other (system level languages) and vary on a case by case basis. In today's todays platforms if you want to allocate an object in your language think of the layers and layers of side effects that will happen. 1. The allocator/GC system allocates it from some kind of pool possibly. Lots of side effects there (like operating on a pool, triggering some kind of collection / cleanup, requesting a large mapping from the OS. 2. Then at the OS level accessing mapped memory has all sorts of side effect (paging, lazy initialization, etc). 3. At the hardware levels there's lots of side effects: instruction cache, multiple layers of data caches, TLB, DMA. In conclusion, for some kinds of problems you don't need to worry about these details and for others you can't afford to ignore them.