PureScript + learning Erlang/Hakskell rekindled mine :)

I ended up learning Erlang after hearing about Elixir and not being a fan of the Rubyish syntax and immutability comporomise, which has been a very rewarding experience. Haskell even more so. And Purescript has some nice Elm inspired libraries [2].

[1] https://purescript.org

[2] https://github.com/search?utf8=%E2%9C%93&q=language%3Apuresc...

pedant mode on...

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.

> Elixir is entirely immutable - it has to be as it just runs on the Erlang VM!

No, variables are mutable in Elixir.

   Interactive Elixir (1.1.0-dev)
   iex(1)> x=1
   1
   iex(2)> x=2
   2

Notice how x is 1 then x is 2. Variable x mutated.

In Erlang:

   1> X=1.
   1
   2> X=2.
   ** exception error: no match of right hand side value 2

Variables are immutable in Erlang.

I suspect you misunderstood gp's post and thought they were talking about data, which is immutable in both languages in general.

Actually, variables in Elixir can be re-binded:

> 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.

> the structure [1, 2, 3] still exists in memory, but now the variable x is bound to the value 2

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 ;-)

It's not mutated or changed it points to a totally different memory location. It's called immutable data not immutable identifiers. Immutable data is what eliminates a large number of potential bugs. Having a ton of intermediate variable names could actually be a source of bugs plus you have to care if someone reuses the name above the point in code you used it. By allowing rebinding you only care about the code below the place your introduced a variable.

> It's called immutable data not immutable identifiers.

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 obviously phrased it poorly as not to copy too much text the post by Jose Valim on the topic: http://blog.plataformatec.com.br/2016/01/comparing-elixir-an...

This summarizes my thoughts on "compromise" exactly. It may be a good thing to some people but it was still a compromise to change it for potential benefit in exchange for some potential loss of strict identifier immutability.

I prefer the way Erlang does it. But I get why Elixir did what they did as well.

a simple illustration of rebinding vs mutation

  def t() do
    x=1
    f=fn -> x end
    x=2
    f.() 
  end

will return 1

I did not misunderstand. You're calling renaming something mutation. It isn't.

You're referring to static single assignment. This has been covered before in more detail than I care to go into.

> You're calling renaming something mutation. It isn't.

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.