CODEWITHSUNDEEP
functional-programmingerlangimmutability
t0il3ts0ap
t0il3ts0ap

Reputation: 550

What is the need for immutable/persistent data structures in erlang

Each Erlang process maintains its own private address space. All communication happens via copying without sharing (except big binaries). If each process is processing one message at a time with no concurrent access over its objects, I don't see why do we need immutable/persistent data structures.

Upvotes: 2

Views: 1444

Answers (3)

Alexey Romanov
Alexey Romanov

Reputation: 170745

Erlang was initially implemented in Prolog, which doesn't really use mutable data structures either (though some dialects do). So it started off without them. This makes runtime implementation simpler and faster (garbage collection in particular).

So adding mutable data structures would require a lot of effort, could introduce bugs, and Erlang programmers are nearly by definition at least willing to live without them.

Many actually consider their absence to be a positive good: less concern about object identity, no need for defensive copying because you don't know whether some other piece of code is going to modify the data you passed (or might be changed later to modify it), etc.

This absence does mean that Erlang is pretty unusable in some domains (e.g. high performance scientific computing), at least as the main language. But again, this means that nobody in these domains is going to use Erlang in the first place and so there's no particular incentive to make it usable at the cost of making existing users unhappy.

I remember seeing a mailing list post by Joe Armstrong quite a long time ago (which I couldn't find with a quick search now) saying that he initially planned to add mutable variables when he'd need them... except he never quite did, and performance was good enough for everything he was using Erlang for.

Upvotes: 5

Roman Rabinovich
Roman Rabinovich

Reputation: 918

how would this work?

factorial(1) -> 1;
factorial(X) ->
    X*factorial(X-1).

if you run factorial(4), a single process will be running the same function. Each time the function will have it's own value of X, if the value of X was in the scope of the process and not the function recursive functions wouldn't work. So first we need to understand scope. If you want to say that you don't see why data needs to be immutable within the scope of a single function/block you would have a point, but it would be a headache to think about where data is immutable and where it isn't.

Upvotes: 0

aronisstav
aronisstav

Reputation: 7914

It is indeed the case that in Erlang immutability does not solve any "shared state" problems, as immutable data are "process local".

From the functional programming language perspective, however, immutability offers a number of benefits, summarized adequately in this Quora answer:

The simplest definition of functional programming is that it’s a programming paradigm where you are transforming immutable data with functions.

The definition uses functions in the mathematical sense, where it’s something that takes an input, and produces an output.

OO + mutability tends to violate that definition because when you want to change a piece of data it generally will not return the output, it will likely return void or unit, and that when you call a method on the object the object itself isn’t input for the function.

As far as what advantages the paradigm has, composability, thread safety, being able to track what went wrong where better, the ability to sort of separate the data from the actual computation on it being done, etc.

Upvotes: 4

Related Questions