[gregors]

I've got in-depth experience with many Rails apps and quite a few Phoenix apps (and many other stacks). I used to agree with your opinion, though I think Rails no longer holds a massive edge. Phoenix is now just as effective at releasing real-world products especially run-of-the-mill web apps. And when things get complex after a bit of time (usually due to business logic evolving) - much more effective.

The place where I feel Rails still holds an edge is the massive amount of gems available, but hex is absolutely catching up and I'm only running into missing packages/libraries when I'm doing "weirder" things these days. The ecosystem continues to evolve for the better. On the other hand Phoenix destroys Rails in any realtime scenario. Maybe those edge cases matter to your particular project then again maybe not.

[ericb]

> On the other hand Phoenix destroys Rails in any realtime scenario.

The Rails realtime story is going to be radically improved in Rails 8! I've been using the Turbo beta, and it is magical.

With 3 lines of code each, I made my index page, and show page live, and real-time updating.

I think Phoenix has something similar--perhaps it was the inspiration?

[cultofmetatron]

> I think Phoenix has something similar/

phoenix's channels (for realtime) is the only multiclustered websocket solution with long polling fallback that I know of that will scale to thousands of users out of the box. My startup uses websockets and its never been a bottleneck vs the headaches I've deal with doing similar stuff in nodejs. its just an absolute unit for doing realtime.

And now they have liveview which takes that and builds on it to accomplish magic.

rails has done great things but comparing it to phoenix on realtime stuff is like comparing a moped to an f16

[ericb]

> comparing it to phoenix on realtime stuff is like comparing a moped to an f16

Have you tested this? I ask because under the hood, Rails is using Faye, and Faye is using EventMachine.

About 10 years ago I load tested Faye vs. Node in a websocket scalability test for a websocket based chat app I was writing, that, funnily enough had a polling fallback. We had scalability needs up to around 10k or 20k simultaneous connections if I remember right and I wanted to know their ceilings before we wrote the real code and invested in either.

Faye kicked Node's butt on simultaneous connections and throughput. Node fell over while Faye was still going. Eventmachine, which Faye uses, can scale like nobody's business. It IS an F16.

[cultofmetatron]

I worked at a startup using rails. I also spent several years as a nodejs engineer.

I built my startup in elixir.

having experienced all 3, I can tell you in real world perfrmance, the metaphor is accurate. if you're boostrapping a startup and you need fast, stable websockets. elixir is the GOAT.

[karmajunkie]

yeah, elixir is still going to destroy it at runtime. the concurrent story is even more important with the features you’re talking about and especially in that segment, it’s not even close.

[firemelt]

can you give me example when phoenix destroys rails?

[cultofmetatron]

runtime performance for web requests absolutely demolishes rails. its not even close. I was seeing sub 10ms response times in developer mode. database queries end up being the overwhelming botteneck,

Then there's realtime. phoenix channels is the standard. everything else is a janky copy thats issing one or more factors that make it so good. elixir users lightweight threads so there's less overhead per connection which means you can run WAY more connections on a single machine. Live view takes this further but allocating a persistent process per user on which state can be synced to the frontend without writing ay javascript.

ruby on rails has more and better gems when your'e starting out but once you get some traction, maintenance on an elixir app is much easier due to it being functional.