Will learning Erlang really help in being a better Phoenix or Elixir developer or is it a waste of time?
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.
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.
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.
is one of the best architectural books about the BEAM and OTP ecosystem
This page highlights syntax difference between Elixir and Erlang. It’s a nice start if You want to read code in both languages.
The problems some people have with
. 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.
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.
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
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 https://github.com/standard/standard/issues/78).
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).
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).
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.
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
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). ^.^