[dcolkitt]

Question from someone who's never tried Erlang/Elixir but is interested.

If you're starting a greenfield project in 2020, is there any reason to use baseline Erlang instead of Elixir? I get the impression that Elixir is a strict improvement (besides legacy compatibility). But this is a very very uninformed impression.

[kungfooguru]

Try both. It may be because I've been doing Erlang so long but I still prefer it and its tools (like rebar3 and Common Test). I find the syntax more consistent, less verbose and the lack of Elixir style macros to mean less confusing third party libraries.

But I do think Elixir has its strength in web applications. The macros make Phoenix and Ecto much simpler for building full web applications and if I were building a full fledged interactive web application I'd reach for those.

So mainly personal preference, you may find Elixir preferable, but all that to simply say it is not a "strict improvement".

Oh, and one none personal preference reason: it is nice to do libraries that don't benefit from being written in Elixir (like postgrex and jason get a lot of performance out of using macros so there isn't an argument to write those in Erlang) and aren't specific to Elixir (like a Plug adapter) in Erlang so they are more easily usable across BEAM languages, a list that continues to grow.

[randito]

If you're interested in Erlang/Elixir, you might want to watch this video: https://www.youtube.com/watch?v=JvBT4XBdoUE (GOTO 2019 • The Soul of Erlang and Elixir • Saša Jurić)

It shows off the power of the BEAM VM -- and kind of makes you stand back and go "whoa.. how do they do that?"

[ihumanable]

I work in Elixir most of the time but can read and write Erlang reasonably well, here's my two cents.

Elixir's syntax was inspired by ruby and so if you've used ruby or look at ruby code and think, "yea, I get what's going on here" then you will likely find working with Elixir's syntax preferable to Erlang. Erlang's syntax was based off of Prolog and so it will be less familiar, unless you have done a bunch of Prolog programming.

Elixir layers on a bunch of things that are very nice to have at a language level, the ability to rebind names is probably the one that most impacts code. In Erlang you can't rebind a variable, so Erlang code ends up either using lots of very small functions of having variables like `n` `n2` `n3`. It's not that you can't write good, clean, easy to reason about code in Erlang, but if you are coming from a language with mutability and variable rebinding, it's a bit of a culture shock. I find that Elixir hits a nice medium ground to allow you to wrap your head around immutable data structures, functional programming, actor model, OTP without ALSO having to climb the hills of unfamiliar syntax and some limitations (like variable rebinding) that aren't strictly necessary.

From a tooling standpoint, I find Elixir to be a bit more pleasant than Erlang. Mix (build tool) is great, ExUnit (unit testing) is great, ExDocs (docs generation) is great, Hex (package management) is great. The Elixir community has somehow stayed pretty unified when it comes to tools and for the most part they work really well.

From an interoperability standpoint, you really don't leave anything behind choosing to use Elixir over Erlang. Erlang dependencies work just fine, and the interop is so easy, here, I'll give you an example.

Want to use an Erlang module directly from your Elixir code, here's an example of how to use the timer module.

  :timer.seconds(1)

That's it, that's the interop, you don't have to import anything weird, you don't have to fence off your code, you don't have to juggle types from Elixir types into Erlang types and back again. Want your Erlang interop to look more like elixir, two lines of code.

  alias :timer, as: Timer
  Timer.seconds(1)

Overall the Erlang and Elixir communities are friends (and Gleam, LFE, and all the other BEAM Languages). It's a very positive community all working to build great functionality on top of the really cool piece of tech that is the BEAM VM.

[PopeDotNinja]

Speaking for myseld, rebinding variables in Elixir is my least favorite part of the language, and I specifically avoid using the feature.

[ihumanable]

Yea, I'm mostly approaching this from the point of view of learning any new language is climbing a learning curve. If you are coming from most of the mainstream languages (java, javascript, python, etc) you are going to want to rebind things because that's how imperative languages roll.

This is probably colored from my own experience of going from Python (mainly) to Elixir (mainly). As a toy example, imagine having to remove all the negative numbers from a list in the middle of a function.

Most python programmers would reach for a list comprehension after learning about list comprehensions (which is great because they are more FP)

  my_list = [number for number in my_list if number >= 0]

So you pick up Elixir and you are trying to do the equivalent thing after reading through the docs

  my_list = for number <- my_list, number >= 0, do: number

And that works fine, it's my_list is exactly what you expect, no negative numbers.

Let's try the same thing in Erlang

  MyList = [X || X <- MyList, X >= 0].
  ** exception error: no match of right hand side value 

As a new user coming to the language, trying to do something so simple and getting a somewhat opaque error message is a significant degree of friction.

I have found that when I want the old value of a variable to no longer be available rebinding the name is a great way to ensure that. If in the future I decide that I need the old value later on in the function I can always just change the bind to some other name easily enough, but it prevents me from using state when I meant to use updated_state.

Not to say one way is better than the other, I just found this use of rebinding to work well for me by making it "impossible" to use the old / stale / out-of-date value.

[sodapopcan]

I'm on the fence about re-binding variables. I don't really mind it and have gotten used to the pin operator when I need it. I actually use variable re-binding quite a bit but always only in situations where I want a prime.

  def foo(bar) do
    bar = decorate(bar)

    {:ok, bar}
  end

I like that better than calling it something like `new_bar`. I kind of wish there was prime syntax along the lines of `bar' = decorate(bar)` but I can deal with re-binding when only used like this (and really, the stakes are low). More complex cases can generally always be handled with piping.

[dnautics]

my preference is to only use rebinding if I need to rename something more than once (can happen, in with blocks), and when I do it I postfix-sigil with ! as a code annotation to remind myself to watch out when refactoring the code.

    def foo(bar!) do
      bar! = decorate(bar!)
      bar! = some_more(bar!)
      {:ok, bar!}
    end

[sodapopcan]

Ha! That's a new use of `!` I haven't seen :) But I suppose we are saying completely opposite things. I use rebinding only when I re-bind once. In your example, I would use pipes with a single re-bind:

  def foo(bar) do
    bar =
      bar
      |> decorate()
      |> some_more()

    {:ok, bar}
  end

[dnautics]

well, I guess I gave a poor example, suppose you needed to destructure that bar! out of an ok tuple.

    def foo(bar!) do
      with {:ok, bar!} <- thing1(bar!),
           {:ok, bar!} <- thing2(bar!),
           {:ok, bar!} <- thing3(bar!) do
        bar!
      end
    end

Inspiration came from julia, where ! at the end of the function means "watch out, one of the parameters is gonna be mutated!"

[PopeDotNinja]

If I get to choose the style, I like doing this...

    bar 
    |> decorate() 
    |> some_more() 
    |> case do 
      result -> 
        {:ok, result} 
    end

[sodapopcan]

I like that. I never occurred to me to pipe into `case`.

[dnautics]

you shouldn't do it in your code, and code linters (well, credo) can check for it and yell at you. I think you might have to activate it currently.

I 100% guarantee you don't miss "immutable variables" in your REPL.

    Pid = module:start_link(...).

oh crap. start_link/n returns {:ok, _}, not naked pid.

    {ok, PidForRealThisTime} = Pid.

[nemetroid]

I used Erlang in some university courses, and once wrote a simple crud app in Elixir/Phoenix, so my experience is somewhat limited.

Erlang's syntax is unusual, but after grasping the concepts I always found the language logical and easy to understand. On the other hand, I haven't been able to get comfortable with Elixir. It's a significantly larger language, which comes with higher complexity (but also lets you write code at a higher level of abstraction). I often found myself only half-understanding the code I was writing (and I always make an effort to fully understand what I'm doing).

And personally I find the Elixir syntax to be among the most confusing and inconsistent (especially when compared to Erlang).

Nevertheless, if I was making something web related, I would definitely go for Elixir (because of Phoenix). If I was making something lower-level, I would probably consider both options.

[zach_garwood]

I think it's mostly a matter of taste which syntax you prefer. Where Elixir has the most advantage, in my opinion, is Mix, the language's build tool / project config / task runner. You use the command line tool to compile your project, run your tests, and any other user-defined task you'd like. And you use the Mix module to define your project's dependencies, environments, and build targets in Elixir code. It's a really nice all-in-one Swiss Army knife compared to the cobbled-together build processes from disparate tools found in other languages.

[rlander]

Why I choose Erlang:

- simpler syntax: there’s no Erlang program that you can’t read after getting comfortable with the language. Seriously. Go read OTP source or Ryaks, everything is extremely clear and explicit. To me, easier to read also means less bugs.

- It’s so different from other languages that, IMO, it makes it easier to “think in Erlang”; the syntax fits so well the semantics that I find it easier to think in terms of processes, patterns and the ocasional recursion when switching from other language (most Erlangers are polyglots IME).

*Edit: Reliable network services (Erlangs sweet spot) are much easier to write and maintain when written in a clear and explicit way. I love macros (consider myself a lisper actually) but I think they’re the wrong tool when writing bullet proof network servers (macros are basically everywhere in Elixir).

[napsterbr]

Personally I see no reason to start a new project with Erlang unless you really enjoy its syntax (perhaps for someone who has a solid background in Prolog?).

With Elixir you get everything in Erlang plus a lot of extremely powerful libraries/frameworks (e.g. Ecto and Phoenix), macros, a friendlier syntax etc.

[dnautics]

It's not an improvement if you prefer prolog syntax (for the record, I personally don't). Everyone likes to say that syntax doesn't matter, but it can affect your time-to-POC, example comprehension, debugability, especially if you're starting a greenfield project.

Otherwise, I would say stick with elixir. It is more opinionated about how to do tests, how to organize your code, how to do documentation, how to deploy, how to use libraries, all of which will make your life way easier, especially for a greenfield project.

[jake_morrison]

I have been using Erlang since 2008, and started using Elixir in 2014.

I much prefer the Elixir syntax. It files off the rough parts of the Erlang syntax, e.g. needing to keep track of commas, periods and semicolons at the ends of lines. The most important thing Elixir adds, though, is lisp-style macros, which makes everything else easier.

This is the post which made me switch to Elixir: https://littlelines.com/blog/2014/07/08/elixir-vs-ruby-showd... We get the best of both worlds: the ease of use of Rails with the power of Erlang.