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.
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.
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.
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.
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.
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
It’s not mutable Vs immutable, it is “value” Vs “binding”.
Even though you can rebind a name, a value never changes.
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.
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.
Well, as soon as you have been fooled by real mutation in a concurrent environment, you’ll learn to value those subtle differences.
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
This we will not agree on.
The immutability word in Elixir seems like the word
unlimited in mobile and internet providers
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.
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.