This is a really nice change for those of us who straddle both languages. I've done a fair bit of work with both ets and the crypto module and having to jump into and out of firefox felt at odds with the rest of the development experience.

You mean "Functional AND utilitarian" because for me these both are very welcome features.

Too many consumer focused products become obsessively new-feature driven development [1], often to have new things to announce, or to appease the loudest whining customers/industry critics of the day (operating systems like MacOS, Windows, and mobile platforms are the classic examples).

Much like in the design world where saying "no" often and pushing back against fanciness is critical, the same in software for pushing towards general structural improvement iterations is key to making good software.

[1] Ignoring of course the bug-fixing-driven development cycle that many projects get trapped in.

The language might be still be over-hyped, but the language implementation itself has reached the plateau of productivity. Which is great, I know of some language ecosystems where true productivity is never, ever reached.

For years now at best you can see 1-2 minor features a year. Mostly its just some design tweaks.

Also shameless plug: we're currently working on an open source messaging product called Papercups [1] if anyone is looking for an Elixir project to hack on!

[0] https://www.papercups.io/blog/elixir-noob

[1] https://github.com/papercups-io/papercups

Dancing around runtime vs compile time configuration seemed like it was one of the "harder" parts of dropping into Elixir.

edit: grammar

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.

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.

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

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)

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

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]

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

Let's try the same thing in Erlang

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

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.

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

    {:ok, bar}
  end

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

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

    {:ok, bar}
  end

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

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

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

    Pid = module:start_link(...).

    {ok, PidForRealThisTime} = Pid.

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.

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

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.

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.

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.

It provides more context, links, and other improvements over the CHANGELOG. I am not sure if it is possible to update the link in the post though.

I was able to find a few jobs, but not a ton (this was a couple years ago). The jobs that are out there all wanted experience but obviously that's hard to do with a new platform. I got an interview with one company that I thought understood that I only had a few months experience as a hobbyist (which means I'll be doing a lot of Googling even for common APIs) but they rejected me. At this point my experience with professional Elixir has not been positive.

I love the language but I'll probably just stay a hobbyist, at least until things change.

Companies like Jane Street make more sense. They use ocaml but they don't expect you to have any ocaml experience coming in, but they also have plenty of resources for training and hiring talented engineers.

I just decided it's one of my hobby languages. If a job comes out of it in the future, that's awesome.

You are experiencing the same global pandemic the rest of us are, right? Remote work and all that? (It’s honestly not for everyone. I prefer some physical facetime myself or I... “get disconnected”)

> not a strongly-typed language

While this guarantees elimination of a class of bug, pattern matching plus guards cover most of the potential bug surfaces there IMHO. I know the language creators have been considering some directions to go, there

I would really appreciate any data that backs this up. Or is this a personal observation written as if it was a consensus? Because if we are going by personal experiences, the community definitely feels bigger and more active than before to me.

Now you may say Stackoverflow isn't a good measurement. In Tiobe Elixir hasn't made it to the top 50 https://www.tiobe.com/tiobe-index/

There is little reason for me to believe Elixir is before it's peak, the data is showing otherwise. Elixir's contemporaries (Rust / Go / Kotlin) are at a totally different place usage wise. So I tend to think this is it for Elixir, it's all down hill from here. If you have data showing otherwise please let me know.

Up until 2017 or so, you could see the Elixir community active on StackOverflow with answers from José, Chris and most maintainers. Then the community collectively moved to Elixir Forum. Wouldn’t you prefer to ask questions where the maintainers can also answer? Per the Elixir Forum stats, the number of active users keep growing.

I won’t comment on TIOBE because you can find plenty of critique elsewhere. For example, in the Redmonk rank, Elixir does fairly well on the GitHub axis, and is ahead of contemporaries like Clojure and Julia, and ahead of other functional languages like Haskell, Ocaml, Erlang, and even F#.

I strongly believe Elixir is before its peak. Elixir is most likely still growing, just not at the same pace as languages like Rust or Kotlin.

That's kinda my point. These are the languages you should compare Elixir to, the esoteric ones. Not to PHP, not to Node or not even Ruby. I doubt this is going to change much.

What I said about Elixir (lack of jobs) is also true for the languages you listed.

You say the language is in decline and none of this is solid evidence that's the case. It just says Elixir devs are not really active in Stack Overflow, which anyone in the community would be able to quickly point out.

I am not refuting the data, I am refuting the flawed conclusions you are drawing from it. You are taking the decline in usage of one service as an overall indicator of the community. I provided a possible explanation. I mentioned the GitHub ranks as counter evidence. But way to go on the ad-hominem.

I do worry about the impact it has on these "popularity tracking" services though, since the discussion living elsewhere might (falsely?) indicate that the language isn't attracting developers.

It's funny because not only is popularity not a good indicator of the quality/utility of a tool, if it is overpopular it can actually hurt things

1. They don't even bother advertising a position in local geographical "general" job boards. (Job postings on LinkedIn cost money for every day you have them up; they're a waste of resources if you can predict with high confidence that nobody will find the role through there.) Instead, they'll advertise globally but targeted to the language's community (i.e. language-specific job boards, forums and chat groups, newsletters, etc.) This is where the people using the language are looking, too, anyway, because they also know that there are too few local opportunities for it to make sense to invest the time in checking local job-boards for a job matching their skillset.

2. They don't bother hiring for the language. Instead, they hire for "experience with [relevant language paradigms]" and "experience with any of [similar, more-popular languages]" and then expect the new hire to learn the language on the job.

My personal job-criterion for hiring Elixir devs is "a polyglot in several different language paradigms, fluent in at least one functional language." I find that that filter actually predicts better whether they'll be a good Elixir dev, than actual experience using Elixir does.

-----

As an aside, there's also the fact that languages like Erlang/Elixir (or the MLs, or the Lisps, or Prolog, or...) tend not to be languages used for everything in a company, but instead tend to be languages used for the secret sauce core component of a company. A lot of the time, companies don't talk about using these languages, even though they do, because they consider them a competitive advantage over their rivals in whatever niche they occupy.

Heroku is an obvious example: much of their architecture was written in Erlang [nearly everything at first], but they never advertised that fact once in any official capacity. Likewise, HFT firms never mention they're using ML or Prolog, but many do, because trading bots are often just souped-up expert systems. The only time you find these things out, is when having a beer with ex-engineers from those companies.

There are a lot of happy devs who can find Elixir work, it depends a lot on location, past experience etc. I do think the number of jobs advertised is fairly low compared to demand. SO on one hand it could lead to high salaries. On the other hand it could lead to not all people landing a job (which if you look at the comments some people here are complaining about).

I.e. I mostly just program for money, so how do I motivate myself to do a side project I'm not interested in, just to learn the language?

I wonder if I could ask my employer for two weeks of time to "rewrite" parts of our backend in Elixir, just so I could scratch that itch, without any of the consequences of it actually reaching production.

Like a programming language sabbatical

Most interesting take-aways from benchmarks are some cases where RabbitMQ processes 30-50% more messages per second. And where a native Erlang JSON library beat NIF C library in some specific tests. The PR link covers this info.

0: https://github.com/elixir-lsp/elixir-ls/blob/master/CHANGELO...

https://github.com/erlang/eep/issues/12