I find Erlang is a bit simpler. Some of the macros and so many ways of doing things in Elixir is a tad too much for me. I may be in the minority here, but I also prefer immutable variables.
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
Contrast that with the otherwise equivalent JavaScript:
let x = 10;
const closure = () => x;
x = 20
console.log(closure())
// 20
Shadowing allows you the convenience of reusing names without the risk of a variable changing out from under you via spooky action at a distance.
Indeed, thanks for clarifying, lolinder. I assumed the audience would be familiar with the differences as it's Elixir vs Erlang here.
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.
It's simpler, but it's also incorrect. There are very real differences between rebinding, reassignment, and mutation. All three are distinct from one another in meaningful ways, so reusing the same term is actually wrong and misleading [0].
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
> There are very real differences between rebinding, reassignment, and mutation.
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.
> To avoid complication, it's simpler to just use "change" and understand that there are variables and data.
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.
I think the more accurate thing to say is Elixir allows you to rebind variable names whereas Erlang doesn't. Elixir will allow you to pin a name though such that the pattern matches against the already existing variable name's value. Talking about mutability I think confuses this.
I've worked with both extensively and I agree that Elixir's rebinding is a bit of a wart. FWIW you can get the Erlang behaviour by using the "pin" operator:
iex(1)> x = 4
4
iex(2)> ^x = 3
** (MatchError) no match of right hand side value: 3
I agree with this sentiment. I programmed in Erlang for more than a decade before Elixir came along and I couldn't see the point of it. When I first picked up Erlang in '99 it was a breath of fresh air. The simplicity of the language blew me away (or maybe I just had a very good tutor).
I can speak on this a bit. I'm fairly new to Erlang, but the team I'm on has been using Erlang since before Elixir was created. So we've been doing Erlang just because it's what we've been using, and the team knows it, not Elixir.
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.
Well, I haven't written any Elixir yet, so I'm probably saying that without really knowing.
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.
So you say `maybe` is better than `with` without ever using Elixir, and `with`? I hope your team is not full of people making blanket statements like this.
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.
TLDR; I prefer the Erlang syntax. Since I use Erlang VM for hobby / side projects, it's easier for me to come back to after some time away.
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 see Elixir developers comfortable with Erlang and vice-versa
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.
Depends on the project, but let's say you're writing something that should or could be made a part of other projects. I might be mistaken and correct me if I'm wrong, but I think it might be easier for an Erlang project to be integrated into an Elixir one than the reverse.
I have been solidly in the just use Elixir camp, but I'm debating that on some new projects. For one, if you want a library to be used in both, it's best to write it in Erlang. Then Elixir can just directly call the functions or you could build Elixir-specific wrappers of the Erlang functions. The other is that Erlang just has a bit of simplicity and rawness about it that I like, not to mention it is the OG language. I would miss piping and variable name rebinding though.
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.
If your working on a distributed system, i think Erlang still has better tooling compared to Elixir. For example common test for integration/system testing and snabbkaffe for trace based testing.
I think that it would come down to personal/team preference. Maybe you need to create a library that can be used in both Erlang/Elixir, so it may make more sense to do it in Erlang.
Everything in this article about OTP, Supervision trees, etc. carries over to Elixir, just with slightly different syntax.
Googling OTP it Erlang comes no 9 in the results. The first three are One Time Password. I think there should be a rule to avoid unexplained abbreviations unless the meaning comes up easily in Google.
Sure: you could just have a list of links with the text "click here" that you hover over to see the url, too. If you haven't worked in the BEAM world those terms packed into a URL might not grab your attention enough to trigger recall, and what are headlines for if not telling us what's on the other side of the click?
Sure, if I spent more than half a second deciding if I want to click something, which I usually don't. This isn't "I can't tell this is Erlang without clicking". This is "there are no obvious signs that it's Erlang without clicking".
“adoptingerlang.org” shows up on the discussion page and the HN main list. No need to click, just to read the word “erlang” that is literally right there. It’s pretty easy actually.
Dude, not everyone knows everything. I'd have to have run into this situation before in order to know to look for erlang in the URL here. Plus, do I ever look at the URL before I click something on HN? no.
I had assumed "OTP" was so incredibly obvious that there was no need to look at the URL, that's all.
> It’s pretty easy actually.
Hindsight is 20/20... blaming user error is pretty cheap when my entire point is that it's easy to make user error.
Quoting the article: "OTP stands for _Open Telecom Platform_, which is literally a meaningless name that was used to get the stuff open-sourced back in the old days of Erlang at Ericsson."
That would be unfitting. OTP started as "Open Telecom Platform", but today the long form is not in use anymore. To quote Wikipedia (with emphasis from me):
"The name OTP WAS originally an acronym for Open Telecom Platform, which WAS a branding attempt before Ericsson released Erlang/OTP as open source."
Today, OTP is the name.
To avoid confusions, it would have been best to add "(Erlang)" before the title.
> "OTP" can stand for different things depending on the context. However, in the context of transportation, it commonly stands for "One-Time Password". In the context of fanfiction, it can stand for "One True Pairing". In the context of Atlanta, Georgia, OTP stands for "Outside the Perimeter", referring to the areas outside of the Interstate 285 loop that encircles the city. Please provide more context if you meant a different usage.
Erlang OTP makes no sense... just like X, or Alphabet as company names
The article itself has a blurb that says what it stands for:
> OTP stands for _Open Telecom Platform_, which is literally a meaningless name that was used to get the stuff open-sourced back in the old days of Erlang at Ericsson.
of course it has to, because no one knows about it... too bad they didnt use it in the title, because even with HN's highly limited title length, I think it would have fit
