That should not be meant to take away from these other projects that do interesting things. It just seems like people needlessly avoid Erlang because it's unfamiliar and they miss something amazing in the process.
Pattern matching and immutability are pretty sweet aren't they? So is homoiconicity and macros.
Did I suggest otherwise?
I find Erlang a harder tool to shoot yourself with than Elixir yet there are definitely some things it could improve on, and not only at the language level (always running xref on compilation would be nice).
Can you please elaborate? I was of the opinion it was the other way around.
An "atom" is an Erlang/Elixir thing, kind of like an enum value. "true" and "false" are implemented as atoms, you might create atoms to represent connection states ("idle", "connecting", "connected", "disconnecting"), or to represent errors ("file_not_found", "no_permission", etc). It's a really useful thing and something I miss in every language that doesn't have it.
In Erlang, a variable is a token that begins with a capital letter ("UserId") and anything that begins with a lowercase letter is either a keyword ("if", "case", "end") or an atom. Since keywords are a finite set, this is pretty straightforward. Module names and function names are atoms, so there's no additional complexity there.
In Elixir, a variable is a token that begins with a lowercase letter, unless it's a keyword or one of the special atoms "true", "false", and "null". An Elixir atom either starts with a capital letter (typically module names) or has a ":" in front of it (":file_not_found") or has a ":" after it when used as a map key ("file_error: :file_not_found" -- both words there are atoms).
So the problem that I run into is that identifying whether a token is an atom and, if so, if it's the same atom as in another spot, requires more thought than I think it should.
My Elixir experience was that there were quite a few cases like this where I hit minor friction. In general, I felt that Elixir code is a little easier to write but a little harder to read and Erlang code is a little harder to write but a little easier to read. I feel like the latter situation should be much preferred.
The reverse colon syntax was a bit wierd, but it (and including the parser assuming that it's in a list when it's the last term) make parameter lists buttery.
The atom for "null" is actually `nil`.
For those who are not familiar, in Elixir you can write
result = value
|> f1()
|> f2()
result = f2(f1(value))
so if you wanted to check on on the values you can do this:
result = value
|> IO.inspect(label: "value")
|> f1()
|> IO.inspect(label: "result-of-f1")
|> f2()
|> IO.inspect(label: "result-of-f2")
Personally I like the Erlang syntax better but most colleagues find it weird.
It’s not a dislike of Erlang as much as it is a joy of Elixir situation.
So Erlang syntax feels natural, I just don't have any use for it on my line of work.
Modern C-family/Algol-family syntax is nice but I certainly welcome trying out other syntax families (in the case of Erlang, Prolog-family).
A syntax should match the semantics of the language. C style is not the only way to design a programming language and does not fit all domains and semantics.