4 ms·

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 als

by 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.
  - ramchip 3y ago
    It's called rebinding, rather than mutation. Good background here: https://dashbit.co/blog/comparing-elixir-and-erlang-variables https://dashbit.co/blog/comparing-elixir-and-erlang-variable...
    - rdtsc 3y ago
      Thanks, but I prefer immutable data vs variables as opposed to introducing a new term. I think it's a bit simpler.
      - lolinder 3y ago
        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 https://dl.acm.org/doi/pdf/10.1145/324634.325436
        rdtsc 3y ago
        > 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.
- dudinax 3y ago
  This would make me choose erlang over Elixer. It's convenient to find an assignment to a variable and not have to worry there might be another.
  - sodapopcan 3y ago
    It really isn't a problem... like, at all as it only affects variables within the same scope. foo = "Hello" if true do foo = "Bye!" end foo # `foo` is still "Hello" here I guess if you have REALLY long functions it could be ¯\_(ツ)_/¯
  - lolinder 3y ago
    Yep, I can see why someone would prefer preventing shadowing even though I don't. I just wanted to be clear on what the actual behavior was.
  - sbrother 3y ago
    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
cmullaparthi 3y ago
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).

by rdtsc 3y ago

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.
- ramchip 3y ago
  It's called rebinding, rather than mutation. Good background here: https://dashbit.co/blog/comparing-elixir-and-erlang-variables https://dashbit.co/blog/comparing-elixir-and-erlang-variable...
  - rdtsc 3y ago
    Thanks, but I prefer immutable data vs variables as opposed to introducing a new term. I think it's a bit simpler.
    - lolinder 3y ago
      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 https://dl.acm.org/doi/pdf/10.1145/324634.325436
      - rdtsc 3y ago
        > 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.
dudinax 3y ago
This would make me choose erlang over Elixer. It's convenient to find an assignment to a variable and not have to worry there might be another.
- sodapopcan 3y ago
  It really isn't a problem... like, at all as it only affects variables within the same scope. foo = "Hello" if true do foo = "Bye!" end foo # `foo` is still "Hello" here I guess if you have REALLY long functions it could be ¯\_(ツ)_/¯
- lolinder 3y ago
  Yep, I can see why someone would prefer preventing shadowing even though I don't. I just wanted to be clear on what the actual behavior was.
- sbrother 3y ago
  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

cmullaparthi 3y ago

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).