[kenrose]

I’m the CTO at OpsLevel, where we’ve been running a Rails monolith for ~6 years. We started on Rails 5, upgraded to 7, and are currently moving to 8. Before this, I worked on Rails at PagerDuty (including splitting a monolith into microservices) and on Shopify’s “majestic” monolith.

The best thing about Rails is its strong, opinionated defaults for building web applications. It handles HTTP request routing, data marshalling, SQL interactions, authentication/authorization, database migrations, job processing, and more. That means you can focus on business logic instead of wiring up the basics.

Rails isn’t as fast or lightweight as Go, but they solve different problems. For most web apps, the bottleneck is I/O, not CPU. Rails optimizes for developer productivity, not raw performance, and that tradeoff is often worth it, especially when speed of iteration matters more than squeezing out every last cycle.

[ksec]

>For most web apps, the bottleneck is I/O, not CPU.

We just have blog post submission on HN that suggest otherwise. At least for RoR.

Luckily we have YJIT and we are finally understanding may be we are actually CPU bound, which means we could look into it rather than always thinking it is a I/O DB Problems.