3 ms·

Frankly, I think the bigger cliche is: “sure, it’s easy to get started, but Rails doesn’t scale!” Rails apps are way over represented among large web-based bus

Frankly, I think the bigger cliche is: “sure, it’s easy to get started, but Rails doesn’t scale!” Rails apps are way over represented among large web-based businesses. Shopify, GitHub, Gusto, Airbnb, etc. There are countless examples of Rails scaling beyond what anyone could reasonably expect their web app to need.

ulizzle 3y ago
Those companies are a product of the last wave, when Rails was very popular in tech, especially amongst San Francisco circles. There are also a lot of examples of that size that left Rails or never jumped on that trend. This is also an argument from survivor bias. You have to count the failures too, which we don't have numbers for. It's not that it can't scale; it's just that it's too easy to make a mess in the way, which would prevent you from doing so. So what ends up happening is that you pay for mistakes or someone else's, but at the end of the day, you are still on your own.
karmakaze 3y ago
I've worked with Rails at two companies: 500px and Shopify. The former was what I take to be typical use of gems and monkeypatching magic. I didn't like it, though I ended up doing myself to get other issues under control. (And luckily much new development were as separate services in Go.) The Ruby/Rails at Shopify is much more sane (by my definition) looking much more like regular API made using a statically typed language (lots of Sorbet type info). There is of course dynamic magic, but tends to be limited rather than preferred, and where feasible static Sorbet type info is generated to match what the magic produces so users of magic can operate as if it was just a static typed library with a bit of DSL. There's enough in-house specifics that I wouldn't even call it Ruby on Rails, but rather Shopify Ruby/Rails and it's constantly evolving. There can be 3 ways of doing something: the old way (being phased out), the current way, and perhaps a new one being tested out in some part of the codebase.
bdcravens 3y ago
This list cements the idea that without massive budgets Rails becomes a challenge once you reach a certain point. The argument against Rails isn't that it can't scale, but that doing so requires a certain level of complexity that is untenable for certain sizes and types of teams. Shopify has built massive tooling (https://shopify.engineering/shopify-made-patterns-in-our-rails-apps https://shopify.engineering/shopify-made-patterns-in-our-rai...). Github was stuck on an old version of Rails for years due to the amount of customization they had done. (It was actually a big deal when they finally were able to run on the latest version: https://github.blog/2018-09-28-upgrading-github-from-rails-3-2-to-5-2/ https://github.blog/2018-09-28-upgrading-github-from-rails-3...)

ulizzle 3y ago

Those companies are a product of the last wave, when Rails was very popular in tech, especially amongst San Francisco circles. There are also a lot of examples of that size that left Rails or never jumped on that trend. This is also an argument from survivor bias. You have to count the failures too, which we don't have numbers for. It's not that it can't scale; it's just that it's too easy to make a mess in the way, which would prevent you from doing so. So what ends up happening is that you pay for mistakes or someone else's, but at the end of the day, you are still on your own.

karmakaze 3y ago

I've worked with Rails at two companies: 500px and Shopify. The former was what I take to be typical use of gems and monkeypatching magic. I didn't like it, though I ended up doing myself to get other issues under control. (And luckily much new development were as separate services in Go.) The Ruby/Rails at Shopify is much more sane (by my definition) looking much more like regular API made using a statically typed language (lots of Sorbet type info). There is of course dynamic magic, but tends to be limited rather than preferred, and where feasible static Sorbet type info is generated to match what the magic produces so users of magic can operate as if it was just a static typed library with a bit of DSL. There's enough in-house specifics that I wouldn't even call it Ruby on Rails, but rather Shopify Ruby/Rails and it's constantly evolving. There can be 3 ways of doing something: the old way (being phased out), the current way, and perhaps a new one being tested out in some part of the codebase.

bdcravens 3y ago

This list cements the idea that without massive budgets Rails becomes a challenge once you reach a certain point. The argument against Rails isn't that it can't scale, but that doing so requires a certain level of complexity that is untenable for certain sizes and types of teams. Shopify has built massive tooling (https://shopify.engineering/shopify-made-patterns-in-our-rails-apps https://shopify.engineering/shopify-made-patterns-in-our-rai...). Github was stuck on an old version of Rails for years due to the amount of customization they had done. (It was actually a big deal when they finally were able to run on the latest version: https://github.blog/2018-09-28-upgrading-github-from-rails-3-2-to-5-2/ https://github.blog/2018-09-28-upgrading-github-from-rails-3...)