Comment by Kerrick

So first it's a bit annoying to read this when I busted my ass for several weeks to refactor Active Record to make it more compatible with the Fiber use case in 7.2.

But also there is very little benefit to it for the vast majority of Rails applications out there.

Unless you are doing micro-services or something like that, your typical Rails application isn't IO heavy enough to run more than 2 perhaps 3 threads before contending.

So the overwhelming majority of Rails applications wouldn't see any benefit from being served via falcon, quite the opposite.

Async is great to enable some use cases where people would have to reach to Node before, but Rails will never be a good solution for that, if you want to do some sort of light proxy or websocket notification thing, Rails isn't a good solution, you want something much lighter.

There's various PRs where Fiber adapters are making their way into the Rails stack. Rails 8 added a ton of support for Fibers, with the exception of ActionCable. There's a PR open for that, which I assume will land sometime soon.

Rails has been really slow to pick-up async/http-2. They don't know it yet, but Falcon and all async libraries Samuel is working on will probably be a huge them 1-2 years out when more people find out it means less infra has to be deployed to production environments. Right now folks are happy to deploy without Redis™ with the Solid stack, but a lot of that won't be needed if proper async support is baked into Rails.

There's been a lot of Fiber features being committed into the Ruby language that I barely understand, but have improved all of these async libraries over the past few years. That's finally starting to bear some fruit for people like myself who don't really understand all of those details, but understand the benefits.

It will happen, but these things tend to play out more slowly in Ruby, which is a feature or a bug depending on how you look at it.

That's not completely accurate. Rails 7.2 added fiber support.

Only action cable still doesn't fully support falcon using http 2. But that's coming soon as well.

My assumption is that’s due to the use case benefits for it.

More concurrency is not always ideal, especially if you’re not in an environment that guarantees you won’t have negative impacts or runaways process (BEAM languages, etc).

Rails projects are typically so hardwired to use a background queue like Sidekiq that it becomes very natural to delegate most use cases to the queue.

Tried GoLang and also used Phoenix for a massive project which went well. But we had problems onboarding new folks into it and some junior and even senior engineers went bonkers trying to get their heads around FP and the elixir language in general. I would say it worked great for me, but the problems and the curve of learning for others in my team made it feel like Elixir creates that gap for teams in general.

Go is good, but again I only tried it long ago and can't comment it for what it is today. I loved Ruby but I find it hard to go back to it after my experience with Elixir and Typescript. I was hoping for Crystal to go to great lengths but it doesn't seem to be the case at all.

I also noticed an elitism from other devs when it comes to Rails devs. I literally heard on multiple occasions "we don't hire Rails devs here!" followed by a laugh.

Of course it was tongue in cheek, if the candidate is amazing yes they're a hire.

But it spoke to a reputation that Rails devs had seemingly received. I think because prior to JS/Node, it was Rails that offered newbies the fastest path into web dev.

I don't believe this is the reason for any sort of exodus, but the negative perception may be partly a reason for devs choosing other frameworks.

> part due to newer options such as Elixir/Phoenix or Golang rising in popularity for backend work

I suspect Django and Laravel have taken a chunk of the market as like for like replacements.

There's plenty of reports of YJIT lowering real world Rails applications latency by 15-30%.

There is also plenty of perfectly snappy Rails applications out there. People need to stop blaming the framework...

I have wondered about that, and I'd guess the thing you (and the sibling comments) pointing out about how GH seems to take an html-fragments approach versus GL opting for the more traditional(?) AJAX one probably does matter a great deal on the end user experience

Regrettably, since GH doesn't develop in the open, it's hard to have an apples-to-apples between the two in order to know if GH has some really, really tuned RoR setup, or it literally is just a matter of "don't be cute" when sprinkling every JS trope known to man upon your web ui and if GL one day cared about their page load times, they, too, could be quick without needing a RoR nor RVM upgrade

both recently had success with adding JIT