[athenot]

There are a handful of languages that would be suitable for this. The "right one" to use depends on more than just the language features for that task:

- What third party libraries do you need to use? Some languages have very good support for some, and less for others.

- What are the internal integrations you need to support? Can they be over the network or are you calling into code in a particular language?

- What is the pool of skills available to you as a team? Do you go with a language that has a reputation of being really good for this task but of which the team knows very little (and therefore will have a learning curve working out the common pitfalls), or do you go with a better understood language which the team has already mastered, and stretch it to go beyond what mere mortals do with it? Note: there's no right answer here, both options have severe drawbacks.

- Related to the previous: what's your company's culture regarding technical diversity?

[anildigital]

This is a very typical diplomatic answer to stick with old, known programming languages.

[arcturus17]

Maybe because a lot of the time it's good advice?

[SketchySeaBeast]

Often case that isn't the wrong way to go. Newer doesn't mean better, and there's always trade-offs to consider. "It's newer" by itself really shouldn't be much of a consideration.

[nevertoolate]

Erlang is older, more suitable, more stable and less well known. Nobody mentioned that it is better because newer.

[SketchySeaBeast]

No, but the person I'm responding to is implying that using old, known languages is somehow a bad thing.

[verttii]

But in this concrete case his point is valid, I'd likewise expect Erlang's BEAM to outperform node.js in concurrency any day of the week. Elixir being new is fairly irrelevant because it compiles down to the same erlang BYTE CODE. Erlang is 30 years old.