My view has always been that I don’t see Erlang (or Elixir) as a language with concurrency but as a system, even OS, with a language. The system side has always been fundamental and the features of the language were designed for building systems, massively concurrent, fault tolerant, etc… systems. That is why they are what they are. We didn’t start out to make a functional language with actors (didn’t even know about actors) the language and its features evolved together with our ideas on how they could/should be used to build systems. That is why some things become almost trivial, I can write a fully functional supervisor in a page of code.

I don’t know if this helps you though. It is a difficult problem and I have always felt that understanding the core semantics and how and why you use them is the most difficult thing when learning a new language. You should see me trying to do classic OO in java or c#

There are multitude of microservices written in Golang, Python, Ruby, Java, etc. and they seem to be doing just fine. As you have seen, this is not enough of an argument to convince people to leave the languages and tools they know and pursue something different. You’re trying to address a pain point which is just not there or is small enough that people don’t care. People won’t jump to another stack for 10% (or whatever the number may be) of quality of life improvements - they’ll rather work on bringing those QoL improvements to their current stack.

I think I sort of have given up on that after leading a merit-driven process to introduce Elixir in a company I worked for. More than half-way through, the whole thing was shut down by the higher management because of newly created engineering team’s policies about the allowed tech stacks. The decision kind of made sense from the company’s perspective, but I got burned out when we were told we didn’t meet the criteria that were actually not known to us upfront (or maybe those were just excuses after the fact…).

From the company’s point of view, in many (most?) of the cases, the technology is secondary to their business. The product is the king; then you need a good team that can consistently deliver. Does it matter what language it’s written in? Use the good enough tool for the job.

From the individual’s perspective, I’d suggest just looking for companies that are already doing Elixir or places where you’ll be in position to dictate the tech stack.

This is coming out pretty negative, but frankly speaking this is what you’re up against when you go out to people. I think an approach that would work is to rather encourage people to try out Elixir instead of convincing them that it’s better. Show them what can be easily done in Elixir but might be hard in other languages (LiveView maybe; but then there’s LiveWire…). Reach out to folks that are genuinely curious and looking for something new to learn. José’s Advent of Code live stream is a prime example.

Sure, that doesn’t makes sense if you are thinking just in HTTP request / response, (which is similar to opening and closing an application)

Unless you want to handle multiple requests concurrently

Some people are already familiar with the advantage of Node.js non-blocking IO over Ruby or Python. However, node.js is still (at least used to be) running in a single OS process while Erlang utilizes all cores out of the box.

On the other hand in Ruby there are servers that utilize multithreading (for example Puma). However, a lot of ruby gems are not thread safe which basically disqualifies their usage in production. Actor-model concurrency and immutability of data minimizes those sort of issues.

Some languages also provide with actor-model concurrency, however, they are lacking the supervision trees!

It’s hard to elevator pitch Erlang. I think the best and concise showing off of the BEAM is