IMO the most important reason for using Elixir is to take advantage of the underlying Erlang VM (BEAM). The VM gives simple tools with very strong guarantees that make it possible to build highly available systems. IMO HA is a crucial property for web servers, and many other kinds of systems that need to run continuously and perform many simultaneous tasks.

With Erlang, it’s easier to reduce an impact of individual failures (and thus keep providing most of the service with no interruption), as well as detect failures and react to them (thus making the system self heal). I’ve seen examples of both in my production systems, and I think it’s a huge win when a system is able to provide as much service as possible, and resume complete service as soon as possible.

I’m not aware of any other platform which gives guarantees as strong as Erlang. It’s certainly not CLR, nor is it JVM. Some languages and frameworks (e.g. Scala/Akka) might resemble Erlang, but they will not give same guarantees. There will always be some hidden gotcha, or an inferior implementation of an Erlang concept. It’s simply due to the fact that the underlying runtime (e.g. JVM) doesn’t provide the same guarantees. IMO, these days only languages which target BEAM (i.e. Erlang, Elixir, LFE) can get such strong guarantees.

I talked a bit about this in my interview for InfoQ, and also in the first chapter of my book (it’s free, so you don’t need to buy the book to read it ).

I’d say this is in fact a weakness of OO. And I should note I’ve been doing OO since around '95, professionally since '01 (including a lot of C#), while I’ve been working with Erlang since '10. So most of my background is OO and I’ve in fact been a happy practicant of OO, until discovering Erlang.

One problem is with mutable variables: it’s easier to introduce a bug due to unexpected mutation. Just a few weeks ago I spent a few hours debugging why something in my JS code doesn’t work as expected, only to discover that I was mutating a var where I shouldn’t have. That can’t happen if data is guaranteed to be immutable.

In OO you can never be sure about that. You can try to use only immutable vars, but in a large code base it’s hard to be certain it’s always true. Moreover, even if your code is immutable, your dependencies might not be, so there are no strong guarantees.

This might seem like a trivial thing, but it is quite important in a complex code base. Knowing that something can’t change when I call a function (since data mutation is not possible) is a big gain. It makes it easier to reason about the code and gives me bigger confidence.

Finally, FP is more explicit (so less magical) than OO. You call a function, pass some inputs, and get the result. In OO, you call a method, and it’s not clear what does it do to the state of the object. You need to read the implementation to understand what has been changed. In a dynamic language it becomes even worse, since when calling some_object.some_method(...) I can’t know what’s the type of some_object. That frequently makes the reading experience harder than it should be.

So while OO can simulate FP, it’s never completely there. After spending a couple of years with FP, my impression is that it’s at least as easy (if not much easier) to manage complex codebase, so I don’t see the need for OO features anymore.

One thing we found very early on is that no language is good at everything. Languages, and their systems, have a specific view of the world and whether this view fits in with the type of system you are building will determine if it is the right choice. OO and concurrency view the world differently. And saying that I can program anything in my favourite language so I don’t need another one is a completely useless argument. If we follow it to its logical conclusion we should do everything in assembler. The issue is not really what I can use but what is best to use.

Another thing we have found is that many (most?) large systems have different requirements in different parts of the system in which case one language will not be best for everything. So very many larger erlang based systems will have things written in other languages. This is relatively easy to do in erlang as it is easy to interface other languages/systems. Often you will find erlang is used as a “concurrent glue” to hold things together and interface between them.

What I say about erlang here of course applies equally well to elixir.

OK, I really haven’t read any replies from the page but I’m going to give you some pros about Elixir.

About the “OO” part

Ask your colleague if he ever heard of Dr. Alan Kay. Kay was the computer scientist who coined the term “Object Oriented Programming”. He invented the paradigm.

The truth is, Elixir is object oriented. In the classical sense. I won’t get into it, but you can check out the rationale here (seriously, go read that article!).
Actually, is C# who can’t get it’s own object orientation **** together. That’s not C# nor Microsofts fault though.

About the “C# can do what Elixir does” part

Well, that’s not actually true. Ask him about compile time macros. Ask him if, with C#, you can do this:

defmodule MimeTypes do
  HTTPotion.start
  HTTPotion.Response[body: body] = HTTPotion.get "http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types"

  Enum.each String.split(body, %r/\n/), fn (line) ->
    unless line == "" or line =~ %r/^#/ do
      [ mimetype | _exts ] = String.split(line)

      def is_valid?(unquote(mimetype)), do: true
    end
  end

  def is_valid?(_mimetype), do: false
end

The whole article can be found here.
Seriously. Take a good look at that code, because it breathes awesomeness. That code is compile time code that goes into the SVN of freakin’ Apache, takes out all the valid mime types FROM THE SOURCE, IN COMPILE TIME, and creates functions for all of them.

I’ve never seen C# code like that.

About the part that Elixir is awesome???

No need to say anything about that. It is. Period.

About the part that Erlang is awesome

Do you know of a project written in C# by a team of 30 people who can do 2 million concurrent connections in a single server, also backed by a large tech company? Well, I do know one in Erlang: Whatsapp.
Which is the base for Elixir. I don’t think I need to say anything more.

About the part of “more job opportunities”

As people from the software area, we all know the game changes too fast. There may not be jobs now, but I’m sure there were a group of people that dismissed Rails back in 2004 saying there would be no jobs for Ruby. And here we are, aren’t we?
I missed the Rails bandwagon, but I won’t miss the Phoenix bandwagon.

Distributed programming is easy with Elixir

C# though? Hell no. In my company we kinda use C# for everything, and I must say that distributed C# is painful. With Elixir, though? Hell, give me 3 machines so I can boost my app up!

Anyways, is great to have different opinions. Elixir isn’t great for everything, and the same can be said about C#. Right tool for the job, always. I hope I could shed some light on some of the many good points of Elixir.