Will learning Erlang really help in being a better Phoenix or Elixir developer or is it a waste of time?
1 Like
Semantically Elixir and Erlang are very similar. So if you are thinking of learning Erlang in order to be âbetterâ (whatever better would mean to you) at Elixir, it probably will not help all that much.
With that said, I would suggest at least understanding Erlang syntax. At some point in your Elixir career, you will most likely need to use an Erlang library for something. At which point, if you need to look into the code in order to debug something, it will very much help knowning Erlang.
4 Likes
Learning Erlang isnât something you need to do from the very beginning. In fact in my personal opinion the best way to put it off is to learn Elixir via Elixir In Action 2e because in a very subtle way you are being prepared for the necessary aspects of the Erlang mindset.
I would also say that Erlang is easier to learn than Elixir provided you can get passed the ant turd tokens. Elixir adds value on top of that through hygienic macros.
Though my personal bias is that I have never been fond of Rubyâs syntax. In fact for people coming from Ruby it can be a bit of a familiarity trap.
A good free resource for learning Erlang is Learn You Some Erlang (itâs good even if you pay for it).
Also
is one of the best architectural books about the BEAM and OTP ecosystem
4 Likes
This page highlights syntax difference between Elixir and Erlang. Itâs a nice start if You want to read code in both languages.
2 Likes
The problems some people have with , , ; and . is truly amazing, and how worked up about it they can get. 
They spend more time writing blogs about how terrible they are than learning. Itâs a strange world we live in. 
7 Likes
Learning is never waste of time.
And for me, learning Erlang made me to be more aware of macros overuse. The less macros there are the better is UX of the library IMHO. Also some concepts of Erlang give nice understanding of how Elixir code works.
I personally have no problem with end of clause/expression/line tokens but the ongoing JavaScript semicolon debate is just a testament to how touchy many people can be when language syntax violates their personal sense of aesthetics or they feel it makes them type characters that in their judgement should be unnecessary.
1 Like
Lua has optional semi-colons between statements. They are not needed but can help catch some difficult to spot syntax âerrorsâ. One is for example the creation and initialisation of multiple variables in one statement:
local a,b,c = foo(),bar(),baz()
However if I forget a comma I can get legal statements which give me strange results:
local a,b,c = foo(),bar() baz()
local a,b c = foo(),bar(),baz()
So I prefer being liberal and adding semi-colons often. A few extra characters are worth it. I would do the same in JS if I was to write it.
Sorry, wandering off topic here 
1 Like
If only there were no optional semis, there would have been no debate 
The problem there is that semis are optional till they are not (for background âNo semicolonsâ is the opposite of practical · Issue #78 · standard/standard · GitHub).
Erlangâs syntax is consistent, I donât get the fuss about it not being that C-like either.
On topic: Learning Erlang definitely helps down the way - Erlang has tons of useful stuff that one can use in Elixir. That said - not something one needs from day 0.
I just think of them as operators, which they are.
, is a sequence operator (combine both sides to a single level sequence).
; is the expression operator (evaluate both sides and return the right).
. is the statement operator (evaluate both sides, no return, only makes sense in erlang between functions).
^.^
It actually quite bugs me when languages treat them as something that isnât an operator, like lua or javascript or elixir does.
Like taking rust, ; is the same as in erlang, itâs the expression operator, evaluate left, then right, then return right. In Rust if you do something like blah ; blorp it returns whatever blorp returns, which also means returning it straight out of a function (last line doesnât take a ; because itâs not a statement separator like in C++, itâs an expression operator).
5 Likes
Until just reading this, I have had an issue with excluding the ; from the last line of my rust functions (at least ones that return a value, it feels like I always add it). This makes so much more sense now that I donât think of it as a statement seperator.
Thank you, sincerly.
1 Like
If it helps you can even put it on itâs own line, or at the beginning of lines, etc⊠It doesnât âneedâ to go at the end, though rustfmt will move it there, but yeah, itâs just another binary operator like + or whatever. ^.^
This is even baked into languages like OCaml, where:
left ; right
It exactly identical to (with warnings/errors enabled):
let () = left in right
Where it even enforces that the left must be a statement with a useless unit value. 
Then again, in rust instead of doing blah at the end you can always do return blah;, which is technically an early return with a no-op expression as the ârightâ operand after it (which seems a bit messy to me, lol). ^.^
1 Like
