This is really exciting news. Lots of folks slam Rails for being slow and inefficient despite there being massive sites using it at scale (Shopify, GitHub, etc.) with very commendable response times and uptime.

At the same time you can still run a single $20 / month server for "smaller" apps even with Rails + Sidekiq + Action Cable + Postgres + Redis all running on the same server to power your solo developed SAAS app with thousands of customers while having a p95+ response time of <= 100ms.

PRs like this just mean things are going to get even better than they already are and is probably a precursor to converting a bunch of Rails internals to use Fibers over time. The best part about it is I as an end user don't need to know the details, I just know my CPU and memory usage will go down over time while runtime performance continues to get better than it already is.

I wonder how long it'll take before the pendulum swings so hard back into the direction of Rails that it shatters even the original growth spikes of Rails from all those years ago. With Hotwire Turbo being a thing now it's very possible to build very nice feeling apps without writing a ton of JS while leveraging good old HTML and HTTP with sprinkles of Stimulus and WebSockets.

The more I think about it, the more I talk myself into believing Ruby / Rails really are a once in a generation combination. It's truly that good for getting real shit done in a pleasant way.

I really hope some sanity comes back to this industry. Rails and Laravel are the best tools by far to build like... 90% of what we build on the internet (Other 10% being offline first apps and stuff like figma, etc).

It just hurts to see how my team, and previous teams I worked with struggle with all the SPAs and microservices, and Go backends and GraphQL nonsense when what we're doing are just fancy crud forms with maybe one or two really interactive widgets overall.

So much time and money wasted just for following fashion.

Calling it "fashion" is disingenuous.

I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself, and the only solution we had was "just restart the server." We also had no typing then, so every bug was a runtime bug. Hopefully it's improved in the years since...

I've been happily running Go backends for the past 7 years now, and they're stable and fast and easy to refactor.

> I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself, and the only solution we had was "just restart the server."

This hasn't been a serious problem in a decade.

> We also had no typing then, so every bug was a runtime bug. Hopefully it's improved in the years since...

The ecosystem has been introducing gradual typing, but even at high scale, types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug.

(ex-Braintree engineer, we processed billions of requests on Rails)

> types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug.

If you took that away from what I wrote, I apologize. I meant that without a compiler and type-checker, you would only find bugs at runtime. In my experience, the vast majority of these would be easily discovered by a compiler. Presumably that experience is shared by Ruby devs since they're now adding type-checking.

> This hasn't been a serious problem in a decade.

That may be true. I haven't had any need to revisit Ruby or Rails since I moved to Go. But it was a serious problem with no workaround, and I've never encountered any scenario like that since switching to Go.

While I do like static typing, I find more bugs because people have no clue about security and they think they can do it better by just tying together a few libraries and storing a jwt in local storage or they forget to handle Prisma exceptions or they didn't know what session fixation is or because they forgot to consider a corner case of foreign key exceptions from the database library, etc, etc than because somebody passed a string where an integer was needed.

Giving up frameworks with 10+ years of hardening and documentation and libraries and support etc just because of coroutines or static types or nice syntax or because that's what google does then I should do it too makes absolute no sense to me.

Yes. And new projects are even better started now with Rails than in the past (aside from the JavaScript hell still plaguing rails).

Active storage and variants make life so easy.

It's not too bad now, set up a Node environment and there's first class support for using vanilla esbuild or if you want to go without Node entirely there's import maps and lots of goodies at the Rails level to help you manage your JS dependencies. Technically Webpack is still supported too but it's vanilla Webpack instead of Webpacker, that's all part of the new https://github.com/rails/jsbundling-rails abstraction for using a number of different JS bundling tools with their stock set ups.

Personally I went with the esbuild + tailwind combo and it's been smooth sailing. I have an example app here https://github.com/nickjj/docker-rails-example.