> but I also prefer immutable variables

Just to clarify in case anyone gets the wrong idea about Elixir—Elixir data is immutable (you can't modify structures, only make new ones) and variables cannot be reassigned, but Elixir does allow shadowing variable names.

The difference between shadowing and reassignment is significant, because it means that this code outputs "10", not "20":

    x = 10
    closure = fn () -> x end
    x = 20
    IO.puts closure.()
    # 10

Contrast that with the otherwise equivalent JavaScript:

    let x = 10;
    const closure = () => x;
    x = 20
    console.log(closure())
    // 20

Shadowing allows you the convenience of reusing names without the risk of a variable changing out from under you via spooky action at a distance.

Indeed, thanks for clarifying, lolinder. I assumed the audience would be familiar with the differences as it's Elixir vs Erlang here.

So it's immutable variables vs immutable data. Both Erlang and Elixir have immutable data. That's the stuff variables refer to. But in Erlang the variables are also immutable, so X = X + 1, just like in basic math, doesn't make sense.

It's called rebinding, rather than mutation. Good background here:

https://dashbit.co/blog/comparing-elixir-and-erlang-variable...

Thanks, but I prefer immutable data vs variables as opposed to introducing a new term. I think it's a bit simpler.

It's simpler, but it's also incorrect. There are very real differences between rebinding, reassignment, and mutation. All three are distinct from one another in meaningful ways, so reusing the same term is actually wrong and misleading [0].

Besides, "rebinding" is not a new term. A quick search on Google Scholar turned up numerous results that predate Erlang itself [1]. The concept of "binding" a variable dates back at least to Alonzo Church with the lambda calculus, and "rebinding" is the natural term for what happens when you bind the same name again.

[0] As an example of the potential for confusion, see JavaScript's `const` keyword, which prevents reassignment but does not prevent mutation. Sloppy use of the terminology here has lead to real confusion among new JavaScript developers.

[1] For example, 1986: "If the problems illustrated by Mesa are to be avoided, the language should provide some method of unbinding or rebinding a previously bound name." https://dl.acm.org/doi/pdf/10.1145/324634.325436

> There are very real differences between rebinding, reassignment, and mutation.

Hmm, what would be the difference between rebinding and reassignment in Erlang?

To avoid complication, it's simpler to just use "change" and understand that there are variables and data. The variables themselves may change or may not change. In Erlang they don't, while in Elixir they do. The data won't change in either language, unless we are playing with NIFs or use atomics or counters.

> All three are distinct from one another in meaningful ways, so reusing the same term is actually wrong and misleading

If we're talking in the context of Erlang is quite simple, it's enough to just say variables are immutable. When it comes to Elixir we need to add a distinction, and that complicates things. When talking about Javascript or C++ or other languages, then more nuances are needed.

> To avoid complication, it's simpler to just use "change" and understand that there are variables and data.

If you're just talking about Erlang, sure. But as soon as you're comparing languages to each other (which you are) then you have to use the precise terminology if you don't want to confuse people. You can complain about the need for the terminology, and you're certainly welcome to prefer the language that doesn't allow rebinding, but that doesn't actually make the terminology unnecessary.

Binding is not a new term. And here, it is the term. No object is getting mutated. The name is rebound. This is also known as shadowing.

I think the more accurate thing to say is Elixir allows you to rebind variable names whereas Erlang doesn't. Elixir will allow you to pin a name though such that the pattern matches against the already existing variable name's value. Talking about mutability I think confuses this.

This would make me choose erlang over Elixer. It's convenient to find an assignment to a variable and not have to worry there might be another.

I've worked with both extensively and I agree that Elixir's rebinding is a bit of a wart. FWIW you can get the Erlang behaviour by using the "pin" operator:

  iex(1)> x = 4
  4
  iex(2)> ^x = 3
  ** (MatchError) no match of right hand side value: 3

Yep, I can see why someone would prefer preventing shadowing even though I don't. I just wanted to be clear on what the actual behavior was.

It really isn't a problem... like, at all as it only affects variables within the same scope.

    foo = "Hello"

    if true do
      foo = "Bye!"
    end

    foo # `foo` is still "Hello" here

I guess if you have REALLY long functions it could be ¯\_(ツ)_/¯

I agree with this sentiment. I programmed in Erlang for more than a decade before Elixir came along and I couldn't see the point of it. When I first picked up Erlang in '99 it was a breath of fresh air. The simplicity of the language blew me away (or maybe I just had a very good tutor).