It is different. It doesn't have a 100% advantage. In some case it just sort of inverted the choice Erlang made -- lower case variables, vs upper case. Lower case module names vs upper case etc.
It has immutable data but not immutable bindings. Erlang has both as immutable. What that means is, you can do x = value1 then x = value2. In Erlang, like in mathematical notation, once you said X=value1 it is value1, it doesn't make sense to say X=value2 (it throws an exception). In either case you can't modify value1 in place for example by saying x[3]=4 or X[3]=4 ( <- I am making up syntax to illustrate here).
Some like it one way some like it another.
Elixir has better meta-programming, which is nice.
In general, Erlang syntax is not the steepest learning curve. The steepest learning curve is to learn to use actors for concurrency and use functional programming for sequential parts. Elixir presents a more familiar syntax but the other learning curve parts are still there.
I can implement any data structure, and if I define reduce for that data structure I get the entire Enum module for free, all tail call optimized.
It means I can mix and match data structures. I can do crazy things like zip a binary search tree and a lazy data stream together and then call take(5) to get the first 5 elements. And all that is required is reduce to be defined for all data structures. Protocols are a big deal.
Well you are making variables mutable. This is bad. One of the great features of Erlang and generally any functional programming language is immutability that makes defensive programming unnecessary. I would like to keep that... The rest of the stuff is great but it does not give enough value to me to not to use Erlang. Actors is a basic concept and message passing is definitely the way to go if you are building a distributed system. One of the biggest problems with Ruby and the imperative languages in general that it was designed for local execution so communication and distributing computation is more difficult than for example in Erlang.
When we talk about variables we usually talk about 2 different things. Values and bindings. Values are the data in the variables ( a list, a tuple, an object), and bindings are names that are used to refer to data ( what the variables is called).
So X = [1,2,3]. in gives you variable binding X and variable value [1,2,3]. Variable value [1,2,3] is immutable in both Elixir and Erlang. You cannot do x[0]=5 in either one and expect the value [1,2,3] to be modified in place. Binding X is immutable in Erlang but not in Elixir. In Erlang you'd do X1=[5,2,3]. and in Elixir you could do x=[5,2,3].
You can argue what is better. I think both approaches are good, there is not one clearly superior in my opinion. Sometimes I take your side and prefer Erlang, because I like having explicit and immutable variable bindings that don't change behind my back. If I make X=[1,2,3], it is going to be [1,2,3] from now until forever.
As far as Actor and distribution stuff all that goodness is still in Elixir. They complement each other more than compete. Both take advantage of the awesome VM (BEAM) -- which I think is a marvel of engineering -- concurrent garbage collection, lightweight processes, scheduling balancing, async IO background threads, binary references, distribution and so on.
The variables are NOT immutable. The bindings ARE mutable.
a = [1,2,3,4]
x = a
x = [1,2,3,4,5]
a == [1,2,3,4] => true
x == [1,2,3,4,5] => true
This is empirically NOT the same as ruby or even mutability.
This is a HUGE misunderstanding of Elixir. Once something is created you cannot modify it, PERIOD, you can rebind variables within the same scope. You cannot change the values.
Same thing is possible in clojure, and nobody questions that its immutable.
EDIT: And to be extra clear this is only within the same function. Not possible across functions, modules or processes.
It has immutable data but not immutable bindings. Erlang has both as immutable. What that means is, you can do x = value1 then x = value2. In Erlang, like in mathematical notation, once you said X=value1 it is value1, it doesn't make sense to say X=value2 (it throws an exception). In either case you can't modify value1 in place for example by saying x[3]=4 or X[3]=4 ( <- I am making up syntax to illustrate here).
Some like it one way some like it another.
Elixir has better meta-programming, which is nice.
In general, Erlang syntax is not the steepest learning curve. The steepest learning curve is to learn to use actors for concurrency and use functional programming for sequential parts. Elixir presents a more familiar syntax but the other learning curve parts are still there.