Other factors: Erlang/OTP base libraries are written in Erlang, so it feels like there is less friction when using them. With a lot of recent language improvements in Erlang like maps, better command line completion, sigils, etc., I feel like I am not missing too much from Elixir's ergonomics.
One caveat might be if I had do a web app, then Phoenix just has a lot of goodies that are nice to have, and maybe then only then I might consider Elixir.
And not make it sound like I am berating Elixir, and to balance things out, I'd like to say the Elixir community is amazing and the collaboration and improvement they've brought to Erlang/OTP are significant in the recent years. It's nice to collaborate and be part one one large BEAM VM community.
Just to clarify in case anyone gets the wrong idea about Elixir—Elixir data is immutable (you can't modify structures, only make new ones) and variables cannot be reassigned, but Elixir does allow shadowing variable names.
The difference between shadowing and reassignment is significant, because it means that this code outputs "10", not "20":
x = 10
closure = fn () -> x end
x = 20
IO.puts closure.()
# 10
let x = 10;
const closure = () => x;
x = 20
console.log(closure())
// 20
So it's immutable variables vs immutable data. Both Erlang and Elixir have immutable data. That's the stuff variables refer to. But in Erlang the variables are also immutable, so X = X + 1, just like in basic math, doesn't make sense.
https://dashbit.co/blog/comparing-elixir-and-erlang-variable...
Besides, "rebinding" is not a new term. A quick search on Google Scholar turned up numerous results that predate Erlang itself [1]. The concept of "binding" a variable dates back at least to Alonzo Church with the lambda calculus, and "rebinding" is the natural term for what happens when you bind the same name again.
[0] As an example of the potential for confusion, see JavaScript's `const` keyword, which prevents reassignment but does not prevent mutation. Sloppy use of the terminology here has lead to real confusion among new JavaScript developers.
[1] For example, 1986: "If the problems illustrated by Mesa are to be avoided, the language should provide some method of unbinding or rebinding a previously bound name." https://dl.acm.org/doi/pdf/10.1145/324634.325436
Hmm, what would be the difference between rebinding and reassignment in Erlang?
To avoid complication, it's simpler to just use "change" and understand that there are variables and data. The variables themselves may change or may not change. In Erlang they don't, while in Elixir they do. The data won't change in either language, unless we are playing with NIFs or use atomics or counters.
> All three are distinct from one another in meaningful ways, so reusing the same term is actually wrong and misleading
If we're talking in the context of Erlang is quite simple, it's enough to just say variables are immutable. When it comes to Elixir we need to add a distinction, and that complicates things. When talking about Javascript or C++ or other languages, then more nuances are needed.
If you're just talking about Erlang, sure. But as soon as you're comparing languages to each other (which you are) then you have to use the precise terminology if you don't want to confuse people. You can complain about the need for the terminology, and you're certainly welcome to prefer the language that doesn't allow rebinding, but that doesn't actually make the terminology unnecessary.
iex(1)> x = 4
4
iex(2)> ^x = 3
** (MatchError) no match of right hand side value: 3 foo = "Hello"
if true do
foo = "Bye!"
end
foo # `foo` is still "Hello" here
However, we recently just decided to start new projects in Elixir rather then Erlang.
One argument a former team member would make against Elixir is that it has almost too many ways of doing things, in some cases. Erlang is a much simpler language. One example he used was sigils. Sure, they're nice, but it also means there's multiple ways to define a binary string, for example. Sometimes it is nice to have a single way to do something and not have to worry about making a decision about it. This example isn't great anymore though since Erlang is getting sigils in OTP 27.
Another argument I can think of is that Erlang is learning from Elixir. Erlang took its maybe expression from Elixir's `with`, and, IMO, the maybe expression is better. They're also adopting sigils.
But, like I said, we ended up deciding to go with Elixir for new projects, so I would be curious to see what reasons other people have for picking Erlang.
The main thing, and maybe I just am missing something, but I don't really understand what the point of the 'do' in Elixir's 'with' is? In Erlang you just have the maybe and anything that would go in that do block would just go inside the maybe expression. That seems a lot better to me.
I also just prefer the look of Erlang's maybe. I think maybe is a clearer name for what the statement is doing and the lack of the 'do' block looks better to me and makes it easier to read.
It's because basically everything in Elixir is a macro :), and the do block is an argument/parameter to that macro:
maybe x do
...
end
# is really
maybe x, do: ...
# which ends up being a macro call with a named parameter
maybe(x, do: ...)
if x do
...
end
# is really
if x, do: ...
# which ends up being a macro call with a named parameter
if(x, do: ...)
But it took me a very long to come to grips with this, too :)
It's similar to a multitude of languages targeting the Java Virtual Runtime (JVM) -- functional, imperative, object-oriented, actor-based -- whatever you want, but they all produce interoperable bytecode.
Bringing static typing to the BEAM is like a dream come true!
It's a young language to be sure, but I see the potential. (Maybe don't bet your startup on it.)
Lots of BEAM's runtime interaction capability is lost without one.
Everything in this article about OTP, Supervision trees, etc. carries over to Elixir, just with slightly different syntax.
You can't go wrong. Inevitibly, which every you start with, you'll learn both.
My personal journay started with learning Elixir. I soon discovered that I was reading Erlang docs, encountering Erlang stack traces, and using many fantastic Erlang lirbaries. I decided I wanted to be build stronger Erlang experience and havn't looked back.
I still create Elixir projects from time to time, especially to leverage Ecto (for databases). Also, on my todo list is to play with the Phoenix (web framework) project.
I'm suspect my journey is rather common, I see Elixir developers comfortable with Erlang and vice-versa. Though, I'm sure each has a perference like a dominant hand. You'll find yours as you explorer this fantastic technology.
I agree with this. I was an "in theory" fan of erlang for a long time, but was always put off by its syntax, which I don't find too pleasing. But after a lot of elixir, and kind of rubbing up against erlang anyway, you sort of can't help but learn it, or at least learn to read it. Once you start using things like ETS, for example, you're going to be reading erlang docs. By the time you even know about ETS, though, you've probably seen enough erlang that it's not scary anymore.
I do prefer elixir - but I admit it's purely a subjective, aesthetic preference. They're both good and I can imagine jumping back and forth as needed.
One thing I will say though is that once you've worked with the BEAM enough you ain't going back. You will rip my genservers out of my cold, dead hands.
At the end of the day, I do think that Elixir has the better tooling ecosystem. Mix, Hex, the formatter, Credo, ExUnit, Livebook, etc. are really nice.