We put these tests together after clients with existing Rails stacks wanted our input on choosing Phoenix or Rails for their specific real-time push features. The benchmark apps are simple – no database, no sessions, but we wanted to set the PubSub patterns up in a way that would give us insights into a wide range of applications. The blog repo contains everything to setup an instance and run the benchmarks yourself:

https://github.com/chrismccord/channelsac

This won't be a popular comment, but I'm posting it anyway.

I'm annoyed by all these comparison posts that only harp on speed and benchmarks. The biggest benefit to using Rails is its ecosystem and maturity. When speed and benchmarks matter, you won't use Rails unless you're ready to throw money at hardware.

In the second sentence, "Phoenix is Not Rails" yet it goes on to compare ActionCable to Phoenix Channels.

All these posts on Phoenix vs Rails really confuse me. How does Phoenix, apart from MVC (and perhaps the folder structure?) compare to Rails?

Speed, benchmarks, and scaling aside, how does it really compare? Rails scales just fine if you throw money at it (a great thing!); Rails also has the Ruby ecosystem — I can guarantee is vastly superior than Elixir's ecosystem.

I digress.

> I'm annoyed by all these comparison posts that only harp on speed and benchmarks.

You know they are not mutually exclusive right? If you want to learn more about Phoenix and potentially how it compares to Rails:

  * A series of articles on the matter: http://cloudless.studio/articles
  * Phoenix guides: http://www.phoenixframework.org/docs/overview
  * Phoenix book: https://pragprog.com/book/phoenix/programming-phoenix
  * Plenty of talks by the Phoenix team, such as https://www.youtube.com/watch?v=MD3P7Qan3pw and https://vimeo.com/131633172
  * Phoenix v1.2 (latest) features: https://dockyard.com/blog/2016/03/25/what-makes-phoenix-presence-special-sneak-peek

There is plenty of material that answers a good part of your questions. If you don't have performance or scalability needs, good for you, but that doesn't invalidate the cases of people who need those.

> Rails scales just fine if you throw money at it (a great thing!);

If you treat development time and money as infinite resources, then I agree it is "just fine". But in practice, the bigger your infrastructure, the more you will have to spend on servers and on your deployment team. Your development team will also have to squeeze the maximum it can from the codebase, often by adding layers of cache, so it doesn't hurt availability and usability when you have spikes in traffic. This seems to have been the main point of the blog post as well: given how those tools behave, how will it impact your development and deployment?