I think your comparisons between languages and frameworks is looking at the problem from the wrong angle.

As has been said in other threads – you should look for the real selling points in the runtimes themselves.

I have just recently answered you here. Is there anything unclear? Anything that didn’t leave you quite satisfied with mine, and others’, answers?

For a quick answer, Erlang/Elixir’s runtime (the BEAM VM) is a perfect fit for any network service – especially web! – except for the cases when you need the last drop of performance per watt, in which case you should go for C++ or Rust or D. The reasons why the BEAM is excellent for web have been already very well documented and my compressed linked answer is, I dare saying, not a bad summary.

Thanks for replying,
I am still learning so please excuse me if some of my questions are redundant to the community, they are not redundant to me because I am not yet aware why they are redundant. I am creating these topics in the chat sections where I am assuming a higher degree of potential redundancy is acceptable. The reason why I am asking what seems to be a similar question from different angles is because I am curious how different infrastructures could benefit from the same implementation. Aka a chat app is totally different from a content management system (in my eyes). Also it’s possible that someone could have different experiences in this particular context and share stuff that wasn’t shared in the previous thread. This wasn’t meant to mean that I am dissatisfied etc. I am just being curious.

It is different only in a business sense and from the point of view of the normal human. They share quite a lot technologically:

1. A chat app requires a solid WebSockets implementation – which Elixir has inside the Phoenix project, whose quality is enabled by the BEAM;
2. A good CMS and a good web app require a runtime that allows thousands or millions of HTTP requests/responses be handled fairly and without one request impeding others which is, you guessed it, what the BEAM is about.

So to help you understand why asking similar questions from different angles could be redundant, ask yourself if the app you have in mind:

• Needs to serve a lot of people?
• Needs to not lag?
• Needs to be reliable?
• Doesn’t need to run as close to the metal as possible? (Example of the reverse would be video transcoding or AI – Deep Learning – calculations.)

If you answer “yes” on all these the chances are very good that Elixir will serve you fantastically.

Conversely, with PHP / Ruby / Python, the web deployments need to resort to all sorts of finicky tricks like keep 20 workers waiting for HTTP requests. What happens when there are 21 or more requests? Those beyond 20 simply wait their turn. If the server is beefy enough you will never notice but the problem is there and will manifest itself in the most inopportune of times.

Elixir’s Phoenix won’t do that. If you get 10_000 requests they all get an OTP process and they all work in parallel (some restrictions apply to database pools but that’s separate).

Lastly, nothing that Elixir can achieve is impossible to be imitated well enough by many others (see Java’s Akka framework for one example). Hell, people write their web apps in C++ even.

But many of us want certain guarantees (fault tolerance, lagless operation, huge parallelism and concurrency abilities etc.). They help us focus on actually delivering value. Our time isn’t 50% - 80% dedicated to operations and system administration. Our time goes to make our customers succeed.

Ask away if anything more is still unclear. Don’t think me hostile, I was legitimately confused about the goal of your question here at first.