Why, if your answer is yes?
No, because the only advantage I see on Erlang it’s that variables are immutable, but that is not enough to overcome the syntax 
NOTE: Please don’t tell me that variables are immutable in Elixir, because rebind, or whatever name people like to use to mask the fact they aren’t immutable.
4 Likes
I really like the language, as it misses a lot of the meta programming features that sometimes make elixir hard to grasp.
Though I miss protocolls in erlang, as well as I’d really like to use some of the elixir libraries in erlang, but as they do a lot of macro-ing, I can not use them from erlang.
And similar as @Exadra37, I really do not like the fact, that variables in elixir are rebindable. Together with the fact that “imperative assignments” do not work anymore, we have a source of big confusion for new commers in elixir.
4 Likes
I love variable shadowing, so I suppose I’m biased, but I think Erlang’s approach would be much more appealing if it prevented more errors at compile time. Reading Jose’s article on the rationale behind the Elixir approach has really solidified my feeling that he made the right call. Erlang’s approach puts a lot of pressure on the programmer not to create the silent runtime errors he describes. I still consider myself a relative newcomer, and shadowing feels really natural to me, so I think it’s only a source of confusion if you are accustomed to something else.
2 Likes
The problem with that article is, that it predates the current behaviour.
When that was written the following code produced a warning explaining that imperative assignment was bad, but xs final value was 2, today there is a warning x beeing unused and its final value will be 1, if you even have a more complex body for the if, then the “unused” warning might even not show up, but the final x isn’t what you expect it to be.
x = 1
if x == 1, do: x = 2
IO.inspect x, label: :x
I’d go even this far, that this was an incompatible change and elixir 1.8 (or was that changed in 1.7?) should have been released as 2.0.
3 Likes
Well, values are immutable. Shadowing isn’t mutation. Once created value will never change.
Variable shadowing has some use cases, for example it is often easier to write tests in Elixir where you do not need to check all earlier variables that you accidentally do not reuse any (happened to me more times that I would like to admit).
For me sometimes it is easier to express some ideas in Erlang than in Elixir. Additionally some tools (for example Leex, Yecc) are very Erlang-centric (and it is easier to use them rather than adding more dependencies.
I also often prefer the Rebar3 approach to some things rather than Mix. Especially plugins and programatically running compilation.
So in general both languages has their use cases and sometimes I use the one that suits the concept more. Additional advantage of Erlang is that it is easier to use Erlang libraries in Elixir rather than using Elixir libraries in Erlang.
4 Likes
No matter what name one uses in the end of the day when I use the variable a second time I don’t have any guarantee that as the same value on it, because it has now a new value on it, thus is not immutable anymore.
So I am not an English native speaker, thus I went to Google to ask for the definition of immutable:
So it seems pretty clear that the definition of the word Immutable doesn’t match the Elixir behavior about variables.
Now I know that behind the scenes the variable is pointing to another memory address that contains a new value and that is why people use a lot of fancy names to not admit that Elixir is not immutable when it comes to variables.
About the rest I agree with you
2 Likes
It’s not mutable Vs immutable, it is “value” Vs “binding”.
Even though you can rebind a name, a value never changes.
4 Likes
Who cares that the value stays there in the same memory address unchanged, if it’s now lost forever in my program… aka I cannot get it anymore because the variable is now pointing to another memory address.
2 Likes
Well, imagine word “castle”. When we speak about the castle then we always mean one, concrete, immutable castle. Even when in another sentence it may mean another castle.
Immutability is about value not it’s name. We can have immutable variables with reassignment and mutable variables with single assignment. Example in Erlang we have single assignment, yet ETS tables are mutable.
3 Likes
Well, as soon as you have been fooled by real mutation in a concurrent environment, you’ll learn to value those subtle differences.
5 Likes
I understand perfectly the differences you are talking about, but no point in continuing the discussion, because I will continue to not change my opinion regarding how the Immutability is framed on variables in Elixir.
Thanks for trying 
2 Likes
This we will not agree on.
The immutability word in Elixir seems like the word unlimited in mobile and internet providers
2 Likes
Well, you could ask “why not?”
Erlang and Elixir have so much in common, the differences are almost negligible.
One of the advantages of Erlang is that the community is full of hardcore OGs who have been woking on distributed systems for 30+ years. The level of knowledge and experience there is absolutely fascinating!
I don’t look at it as “one or another”. It will tremendously help any Elixir developer to learn Erlang and dive into Erlang resources. Will make you better Elixir practitioner too.
6 Likes
I didn’t look at that aspect of it. An average Erlang developer is of course much more talented and experienced than an average Elixir programmer.
2 Likes
Oh yes, because of Erlang Devx…
3 Likes
The Erlang syntax is much simpler and more consistent than Elixir’s. There are too many weird rules you just have to know about to get Elixir to work. For example you cannot write:
with
{:ok,x} <- do_something()
....]
And yes I know why.
5 Likes
Whoo hooo!!! Robert’s first post on Devtalk ^^ 
On topic…
I’d add that if you use Elixir you will find you’ll be using or interacting with Erlang directly at some stage anyway, because you are probably going to end up using one of the many Erlang libraries that the Erlang community have built up over decades. Many people have said it will help with your understanding of Elixir as well.
Personally I just want to learn it anyway. Not just because of the above but also because I have a feeling of fondness towards Erlang which is difficult to put into words. I think it’s in part because how Robert, Joe and other Erlangers have welcomed and interacted with us over the years (Robert has been on our Admin team on EF since pretty much day one and Joe joined it just before he passed away) combined with just how ahead of its time Erlang was and how it still remains a leader in its field today; giving it that rare combination of maturity and coolness that makes it iconic 
3 Likes
This piqued my curiosity so I looked. Imperative assignment was deprecated back in 1.3 in 2016. Time flies, huh.
@benwilson512 noted a clever and simple workaround where instead of trying to rebind the variable to the conditional clause’s return value, you rebind to the entire conditional clause itself. Hmm, I’m not sure that I’m saying that correctly let alone clearly, so using your example:
x = 1
x =
if x == 1, do: 2
# x == 2
Do you think that still poses a problem? Not obvious and presents barriers to newcomers? Too much of a breaking change?
2 Likes
That snippet posses the problem that if the condition is false or nil, x will be nil after the if, due to the implicit else: nil.
Therefore you always have to write both branches out:
x = 1
x = if today_is_sunday, do: 2, else: x
4 Likes