It’s more than “just an idea”. It’s how Erlang works. And the Elixir core team is aware of that, but decided on a rebindable approach instead. Elixir is not going to change this feature. If it deeply matters to you, then I recommend you explore Erlang more deeply.

Let’s try to unpick this argument.

First, let’s see a javascript example of mutability:

a = {}

// b holds a reference to the same data as a
b = a

// mutability: we're changing the data
a.x = 1

// data pointed to by b is implicitly changed
console.log(b) // {x: 1}

Now let’s see a javascript example of rebinding:

a = {}
b = a

// rebinding: a points to different data
a = {x: 1}

// rebinding a didn't change anything in b, hence it's not mutability
console.log(b) // {}

The former (mutability) is problematic because it’s much harder to reason about the code. For example if we invoke foo(a), we have no way of knowing if this will change something in a. We need to read the code of foo and all the code it invokes (recursively!) to reliably answer that. This is extremely tedious, prone to errors, and whatever assumptions we have about the code today can implicitly change tomorrow without us knowing it, for example if a team member changes some indirect dependency of foo.

The latter (variable rebinding) doesn’t suffer from such problems, because rebinding doesn’t change the data.

José wrote about rebinding in Elixir and Erlang in detail here: