Yes, my position is that for simpler projects Elixir will help simplifying the tech-stack. So while I see occasional complaints that Elixir is an overkill for smaller projects, I personally think that with Elixir we’ll produce simpler solutions for simple problems, and at the same time we’re certain it can take us very far if things become more complex.

This 1000 times. I’m working on very small scale projects that run on a single machine. Not having to install a ton of packages for common functionality is a huge boon. In fact I’m thinking of collecting all this philosophy into a talk for some next ElixirConf… my working title is “Scaling down with Elixir”.

I think others have answered your specific questions, but I’d just like to address a more general point, since this table tends to be misinterpreted in a couple of ways.

It’s worth mentioning that this table is a true story, not a contrived example. I was working on these things side-by-side, and Server B was implemented in plain Erlang, as a single project. Moreover, having been involved in server A from the very start, there was no doubt in my mind that we could have moved most (if not all) of it to Erlang. In fact, since we had a lot of problems in production with server A (unlike server B which had almost no problems), I proposed we move it gradually to Erlang, and argued that this move will solve many of our problems. Reflecting back, I still feel the same.

I however caution against a general conclusion that Erlang can always replace 3rd party products. In more complex cases, an external component will likely be a better choice than a built-in Erlang option. That said, Erlang tools (such as processes or ETS tables) can definitely handle many different scenarios, so my feeling is that compared to other languages (especially scripting languages with no proper concurrency story), an Erlang (or Elixir) based project will in general require less 3rd party products and external OS processes.

Hey there and welcome!

Saša’s list is, of course, a little tongue-in-cheek but ultimately true.

Let’s look at some of the points from the list:

1. HTTP Server: You don’t need to use a third-party public-facing HTTP server because the solutions written in Erlang (like Cowboy) are ready to handle this already.
2. Redis/Sidekiq: You don’t need to use third-party software for handling background data processing or in-memory caching since this can all easily be achieved with Elixir/Erlang processes.
3. It’s kind of a running joke in the community to ask whether you even need an external database. Theoretically, you could also use Erlang’s in-memory database ETS and occasionally save it to your hard disk. But many people like to use SQL or noSQL database and they work just fine with Elixir/Erlang.

Regarding the advantages of concurrency when you eventually still end up writing to a database: Well, not every HTTP request needs to write something to a database and even then, you profit from increased stability, responsiveness and availability of your sever if it is able to handle concurrency better

I can’t really think of use-cases in which you’d want to go with Ruby over Elixir/Erlang. There are, however, cases in which you might want to go with a language that compiles to native code (like C/C++/Rust) instead in order to get some performance benefits.

There are some nice introduction books and courses for Elixir out there. I have personally read »Programming Elixir« and it covers many important aspects of both the language and Erlang/OTP.

I can also recommend this little video series about GenServer and Supervisors on YouTube if you want to get a quick fix:

I think this is a wonderful idea!

Many of us try to promote Elixir by talking about more complex scenarios such as massive scalability, fault-tolerance, and high availability. I believe that this leaves many people with a feeling that Elixir is an overkill for their smaller-scale problems.

Having a talk which showcases how in simple scenarios you can do a bunch of things with Elixir alone, without needing to reach for external products, might help people understand that Elixir is not only made for large-scale systems, but can also do wonders for smaller ones.

This is precisely why I feel that Elixir is a win-win technology. It leads to simple solutions for simple problems, yet at the same time it can take us far, so we don’t have to consider swapping it for something else down the line.

You should totally submit such talk, and I hope I’ll be there to see it live