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
