> For single a web api server Elixir is going to be far behind, performance wise, against nodejs, the JVM and Go.
To some Go web api frameworks perhaps.
To the JVM, not really. The frameworks I used with it in the past (spring/play/coupleOtherSmallOnes) are throttled to the number of threads for concurrent connections. The BEAM (Erlang/Elixir) has no such limitation and it blew away my old Java servers handily just due to its concurrency alone.
And not to nodejs at all. Running a single BEAM vs a single node there is no comparison, the BEAM runs circles around it. With nodejs you can shard it out to multiple running instances to get concurrency better but you run into OS limits far before the workload that the BEAM can handle.
I believe what Overmind meant was that a single request in another language can probably beat Elixir in performance, but Elixirs ability to handle a large amount of requests concurrently means that it'll have better throughput.
For example, if a web request in framework A takes 100ms and framework B takes 200ms, but framework B can handle 4,000 requests concurrently and framework A can handle 1,000 requests concurrently, then framework B will beat framework A in handling 20,000 requests.
framework A - (20,000r / 1,000r) * 100ms = 2,000ms
framework B - (20,000r / 4,000r) * 200ms = 1,000ms
To some Go web api frameworks perhaps.
To the JVM, not really. The frameworks I used with it in the past (spring/play/coupleOtherSmallOnes) are throttled to the number of threads for concurrent connections. The BEAM (Erlang/Elixir) has no such limitation and it blew away my old Java servers handily just due to its concurrency alone.
And not to nodejs at all. Running a single BEAM vs a single node there is no comparison, the BEAM runs circles around it. With nodejs you can shard it out to multiple running instances to get concurrency better but you run into OS limits far before the workload that the BEAM can handle.