8 ms·

Just out of curiosity for anyone starting a new Erlang project: Why use Erlang over Elixir?

mekoka 3y ago
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.
Miner49er 3y ago
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.
- square_usual 3y ago
  What do you think is better about the maybe expression? Just curious, haven't looked into it too deeply and I thought it behaved exactly like when.
  - Miner49er 3y ago
    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.
    - nesarkvechnep 3y ago
      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.
    - troupo 3y ago
      > I think maybe is a clearer name for what the statement is doing and the lack of the 'do' block 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: ...) Same goes for many (all?) other things in Elixir: if x do ... end # is really if x, do: ... # which ends up being a macro call with a named parameter if(x, do: ...) And so on. But it took me a very long to come to grips with this, too :)
      - square_usual 3y ago
        I think GP is talking more about the fact that you can have a do block, not about what it is.
        Miner49er 3y ago
        Yeah exactly, in Erlang the 'do' portion would just go in the same code block as the conditionals.
denvaar 3y ago
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.
waynesonfire 3y ago
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.
- sho 3y ago
  > 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.
pmw 3y ago
Those two aren't even the only options. There's also Lisp-Flavored Erlang (LFE), and maybe other languages targeting the virtual machine BEAM. https://lfe.io/ https://lfe.io/ 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.
- lawn 3y ago
  I'm personally a big fan of Gleam. 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.)
  - lpil 3y ago
    I would definitely bet my start up on Gleam!
    - slekker 3y ago
      Congrats on the upcoming v1 release!
  - vegabook 3y ago
    but does it have a REPL? Lots of BEAM's runtime interaction capability is lost without one.
    - lpil 3y ago
      Gleam can be used from the Erlang REPL easily, there's no additional runtime/overhead or complex translation between the two languages.
- gregors 3y ago
  also Lua in Erlang https://news.ycombinator.com/item?id=29703949 https://news.ycombinator.com/item?id=29703949
rdtsc 3y ago
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.
- deleted 3y ago
  [deleted]
- lolinder 3y ago
  > but I also prefer immutable variables 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.
  - rdtsc 3y ago
    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.
lpil 3y ago
I prefer the simplicity of Erlang, Elixir is a much larger language and has some quirks.
schneebyte 3y ago
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.
bmitc 3y ago
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.
- LorenzoGood 3y ago
  Also, Phoenix and Liveview.

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.

Miner49er 3y ago

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.

square_usual 3y ago
What do you think is better about the maybe expression? Just curious, haven't looked into it too deeply and I thought it behaved exactly like when.
- Miner49er 3y ago
  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.
  - nesarkvechnep 3y ago
    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.
  - troupo 3y ago
    > I think maybe is a clearer name for what the statement is doing and the lack of the 'do' block 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: ...) Same goes for many (all?) other things in Elixir: if x do ... end # is really if x, do: ... # which ends up being a macro call with a named parameter if(x, do: ...) And so on. But it took me a very long to come to grips with this, too :)
    - square_usual 3y ago
      I think GP is talking more about the fact that you can have a do block, not about what it is.
      - Miner49er 3y ago
        Yeah exactly, in Erlang the 'do' portion would just go in the same code block as the conditionals.

denvaar 3y ago

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.

waynesonfire 3y ago

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.

sho 3y ago
> 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.

pmw 3y ago

Those two aren't even the only options. There's also Lisp-Flavored Erlang (LFE), and maybe other languages targeting the virtual machine BEAM. https://lfe.io/ https://lfe.io/ 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.

lawn 3y ago
I'm personally a big fan of Gleam. 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.)
- lpil 3y ago
  I would definitely bet my start up on Gleam!
  - slekker 3y ago
    Congrats on the upcoming v1 release!
- vegabook 3y ago
  but does it have a REPL? Lots of BEAM's runtime interaction capability is lost without one.
  - lpil 3y ago
    Gleam can be used from the Erlang REPL easily, there's no additional runtime/overhead or complex translation between the two languages.
gregors 3y ago
also Lua in Erlang https://news.ycombinator.com/item?id=29703949 https://news.ycombinator.com/item?id=29703949

rdtsc 3y ago

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.

deleted 3y ago
[deleted]
lolinder 3y ago
> but I also prefer immutable variables 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.
- rdtsc 3y ago
  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.

lpil 3y ago

I prefer the simplicity of Erlang, Elixir is a much larger language and has some quirks.

schneebyte 3y ago

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.

bmitc 3y ago

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.

LorenzoGood 3y ago
Also, Phoenix and Liveview.