there is no "immutability compromise" in Elixir. Static Single Assignment != Immutability. Elixir is entirely immutable - it has to be as it just runs on the Erlang VM!
I think a legitimate complaint along these lines would be "pinning is confusing and error prone for beginners" and I think it's fair. Christopher Meiklejohn mentioned this on Twitter yesterday, and it's a point that's caught me plenty and I write more Elixir code than most people by far.
No, variables are mutable in Elixir.
Interactive Elixir (1.1.0-dev)
iex(1)> x=1
1
iex(2)> x=2
2
In Erlang:
1> X=1.
1
2> X=2.
** exception error: no match of right hand side value 2
I suspect you misunderstood gp's post and thought they were talking about data, which is immutable in both languages in general.
> x = [1, 2, 3]
> x = 2 # the structure [1, 2, 3] still exists in memory, but now the variable x is bound to the value 2
All data is still immutable, the BEAM itself requires so. Dave Thomas explains this in its "Programming Elixir" book.
I wasn't talking about data, I was talking about variables. Yeah you just called it "re-binded". I called it "changed" or "mutated".
You have a function, and you see x=1 first and print its value. You'd see "1". Then you can have x=2 maybe a few lines or pages below, print it, you get "2". Variable x has changed its value. I even illustrated with a short example.
> All data is still immutable, the BEAM itself requires so. All data is still immutable, the BEAM itself requires so
Agreed. I don't think I ever talked about data being mutable. Having used BEAM VM for the last 5 years, yes, I noticed data is immutable ;-)
immutable/mutable data and immutable/mutable identifiers are two different things. One is not called the other, they are separate things really.
> It's not mutated or changed it points to a totally different memory location
So you said it yourself. It points to a different memory location. So how is x not mutated then? "Mutated" is a synonym for "change", or so I thought apparently.
I don't see how one can look at a variable being reassigned and say "nope, variable didn't change", where it clearly has a new value in the line below.
> Immutable data is what eliminates a large number of potential bugs.
Agreed. Was using Erlang for many years and tried Haskell before. Immutable data is pretty nice most of the time.
> care if someone reuses the name above the point in code you used it.
Wait, is it the opposite of what you were trying to say? Wouldn't you want to care if you are now randomly re-using or changing variables someone else assigned. I thought immutability was a good thing.
> By allowing rebinding you only care about the code below the place your introduced a variable.
Unfortunately in my code base, the code above the place where variables are introduced is just as mission critical as the code after the place. Maybe I am using a strange coding style or paradigm ;-)
I prefer the way Erlang does it. But I get why Elixir did what they did as well.
def t() do
x=1
f=fn -> x end
x=2
f.()
end
You're referring to static single assignment. This has been covered before in more detail than I care to go into.
I think you are confused though ;-) There is no renaming -- x=1, then x=2. Nothing was renamed. x wasn't renamed, it is still variable x. 1 and 2 wasn't renamed, it is still 1 and 2 (could have been a map, or list for example). So what do you think was renamed there?
> You're referring to static single assignment.
No, I am referring to immutable variables. Variables are not changing, they are immutable in Erlang. In Elxir variables change, they can be assigned different values later in a function. If that is not a change i.e. a mutation I don't know what is.