I agree to some extent most people will never need to support millions of users but we could all use a more efficient tool. Also important, it may be better to pay more for hosting to get easier realtime (meteor).
However, i’m afraid that there is a lot of overlap as far as scale. You don’t have to have 50k concurrent users to need Phoenix… a lot of Meteor apps i’ve heard of can only have less than 50 concurrent users before needing additional boxes.
The best i’ve done was a little over a 150 concurrent users per modulus servo (512mb) for a particular app (tuned publications and limited reactivity). For the day a peak was 400 so not massive scale but I needed 4 servers to stay afloat. At $60 a month this isn’t a big deal but scaling larger would be costly.
I mean really they are apples and oranges and hard to compare side by side but if you would have the same app on both systems you can use less resources. I guess that’s the point i’m trying to make is that Phoesnix isn’t just for mega scale, it’s aimed at normal apps but it happens to do it fairly efficiently.
Benchmarking a REST Phoenix API on a 2GB 2-core digital ocean yielded around 58k hits in 1 min or roughly 1000 hits per second before getting errors (23). Max latency was 16ms and best was 14ms. using Blitz.io.
That’s plenty for me needs and offers lots of headroom without needing 4-6 node boxes running in a cluster.
Really for me the most interesting thing is how they handle (soft) realtime data (quite differently). Also not really discussed but the ecosystem is very interesting as well.... there seems to be a high priority on quality and testing which is pretty neat.
I’m most interested in bringing in some things that could help Meteor, whether its the language or framework(s) (though they’re different beasts of course). I’m still developing on Meteor for most projects but high traffic sites may get Phoenix until MDG provides a more efficient solution (which sounds like its in the works).