The answers might be a bit biased here Obviously Elixir.

While Erlang/Elixir is good for concurrency and there is a good amount of prior art for chat apps (like Ejabberd or Mongoose), I can give a cautionary scenario against choosing Elixir or Erlang.

If you work in an organization who has an existing ecosystem, and every person in the organization is reasonably familiar with that ecosystem, then languages and libraries in that environment might be best. For example, if you are in an example that uses mainly JVM with a mix of languages like Kotlin/Android on the front end, Java or Scala on the backend, then I’d reach for Akka or even Spring Boot + WebSockets. Consider the cognitive overhead for an organization to introduce a new paradigm, a new runtime, a new school of thought. If the ‘original developers’ who were interested in Elixir/Erlang leave, then will the existing JVM developers be able to debug the application in production? Add new features? Understand the severity of a VM alert?

Other questions to ask:

• Does it need to ‘scale’? If the backend will have a max of 100 to 500 concurrent users at a time, do you need an ecosystem that is highly concurrent?
• Do you need to develop it in house? Can you integrate in an existing OSS application?
• What are the time constraints? Do you have time to learn a new ecosystem while also developing a new chat app.

Food for thought.

shameless plug: I have a toy chat application deployed here:

The code is here:

Thanks to Elixir, Phoneix, Liveview and Surface, I didn’t have to write a lot of code. It supports a reduced version of markdown in chat, opengraph preview of link and more.

Maybe you want to consider that the people who did this already quite successfully (WhatsApp) used Erlang?

As @kokolegorille mentioned, whether Erlang or Elixir is a matter of taste.
Just if you’re considering a web-frontend you might want to go with Elixir/PhoenixFramework/LiveView…

Thousands or billions of users?
You can easily build a chat app with a few lines of JS and firebase.
If you want to go big, BEAM is the obvious choice.

Regarding concurrency in general.
There are different models how to do that. The most important trait of those is: how do the parts of the system communicate with each other?

1. through shared memory (multithreading+mutexes)
2. messages

(1) tends to be easy at first but good chance it becomes a mess.
(2) harder to get started but better chance of a stable and clear system

(concurrency is hard, there is no easy perfect way)

So beeing on an Elixir forum its no stunner: I vote for message passing.

Go and Erlang/Elixir both use message passing for concurrency. But they are not the same. Go has Goroutines - functions that run concurrently - easy, solid and fun. Erlang/Elixir implement the Actor Model. Not that simple but therefore way more powerful.