9 ms·

The problems with Rails are the same as with Ruby as it was with Smalltalk: just too easy to make a mess (the nature of dynamic languages), and its community su

The problems with Rails are the same as with Ruby as it was with Smalltalk: just too easy to make a mess (the nature of dynamic languages), and its community suffers from a nasty case of groupthink. Notice the cliche "Rails is so much more than a framework." The same magic that makes one so productive at the beginning (start-up stage) is what comes back to bite you in the ass when the project grows into an actual product; unless you are careful and willing to trade off speed-to-market, which isn't what you want to do with a startup. Catch-22 because the app has gone off the rails by the time you are successful, and everyone says: "Oh, you shouldn't have done that."

lawn 3y ago
Incidentally I feel Rust is the reverse Ruby: more work (sometimes much more work) up front, but the big payoff comes in the long run.
- ulizzle 3y ago
  Many typed languages are like that, but the big difference is that they admit the trade-off. In Ruby on Rails, dissent is a big taboo, so they blame the problems on the devs (the unwashed nameless masses) rather than tackle the problem itself. That's why you have all these different tools and concepts; since they try to sandpaper over all the magical complexity by adding more complexity, it becomes a no-true Scotsman trivia game. What trips me up tbh is how tech history repeats itself almost verbatim. The Smalltalk story is very similar but with a different cast.
  - rileyphone 3y ago
    In what way is Smalltalk similar? Its main problem was that it stopped evolving.
    - namaria 3y ago
      All software suffers from this. The whole point of programmable computers is allowing systems of unbounded complexity. Every tooling discussion degenerates into "it's a foot gun" vs "you're holding it wrong". If you remove friction, people will build bigger foot guns. If you install too many guardrails, holding it right requires contortion. The point is not which set of tools you use. There is no substitute for understanding the problem domain, the tools at hand and the labor market you have access to. Everything has a cost, you can't get free advantages from some technical insight or another.
- nickjj 3y ago
  I think there's a large class of apps where you end up writing less than 30-50k lines of code and things aren't a problem in the end. I've built a video course platform now in Flask, Phoenix and Rails and I've built about 60% of the platform in all 3 tech stacks. The Rails app has ~7k lines of code (LOC count includes everything but tests), it's substantially less than the others. The Phoenix app was by far the worst of the 3 in terms of how much code I had to write and overall "difficulty" of the code. The Flask app sat somewhere in the middle, at times it made doing certain things easier and more efficient than Rails but if I had to rank overall developer happiness and how easy it was to do things it would be Rails > Flask > Phoenix where let's say Rails is a 8.5 in terms of happiness, Flask is a solid 7 and Phoenix was maybe a 4 or 5. This includes a number of real-time elements like having a persistent video player that survives across page navigations, notifications and comments being broadcast to all connected clients with authentication and more.
  - uxcolumbo 3y ago
    Surprised about your score for Phoenix. What exactly were the painpoints? My impression was Elixir / Phoenix was ranking high in developer happiness.
    - nickjj 3y ago
      Developer happiness includes all facets of development IMO. The language, 3rd party packages, the overall ecosystem, the community, etc.. Elixir isn't really in the same ballpark as Python and Ruby for package support. Lots of 3rd party vendors don't have official SDKs for Elixir and having to recreate certain components of those SDKs manually can be very tricky. This is especially true for payment gateways like Stripe, Payal, Paddle and others since there's gory details about certain things aren't as easy as making an HTTP call with a token. So you end up having to recreate these things from scratch because most community versions are abandoned due to them being maintained by 1 or 2 people who stopped using it. Also, LiveView's APIs keep changing. The amount of churn was out of control for a few years where it felt like every few months you had to make drastic rewrites to keep up with it all. At the same time the docs are very minimal and community support through blog posts weren't there in the same way they are for Rails and Flask. It felt like you were on your own to solve everything in a fast moving world with an ever growing API. Then for the language, Elixir didn't click for me, even after writing 10k lines of code. I felt like I could get pretty far and understood enough to get most things done but I felt like I was getting stonewall'd quite frequently and couldn't solve certain basic problems after exhausting all pre-existing resources (my brain, docs, blog posts, open source projects, etc.). I don't feel I have this same issue in Python or Ruby. There's such a big community that nearly everything can be found, or at least get you to the point where you can apply something to your domain without asking in chat for help. A good example is https://github.com/josevalim/nested-map-reduce-traversal https://github.com/josevalim/nested-map-reduce-traversal which is something Jose and I worked on a few years ago. If he didn't step in and provide an example on how to do what's essentially a nested loop while modifying a counter in Elixir I would have had to stop developing my project. I still have to step back and spend a full 5 minutes trying to mentally parse his solution where as the Python and Ruby solutions are immediate with no effort. When trying to build a pretty big project, these routine blockers or having to spend 3 hours (or 3 days) down a rabbit hole vs just doing it in a few minutes make a big difference -- this is also after spending months learning the language and ecosystem already. You end up getting fatigued from having to build so many libraries to get to the point where you can work on your main's app goal and it's demoralizing getting hard blocked. There's also this pit in your stomach that's concerned at how quickly you can get stuck in a way that you can't self-resolve. When trying to build a business, these are all very dangerous things. You put all of that together and my happiness level for Elixir was kind of low. It's nothing personal, just my opinion. I think it has good ideas and concepts in places but it didn't feel like the juice was worth the squeeze for someone like me who didn't already have many years of functional programming experience beforehand. Flask and Rails are both fast enough where you can build a million dollar a year business on a single $40 / month server with tens of thousands of customers. You can still get p95+ <= 100ms response times from your back-end in this scenario and both tech stacks have a good story for using websockets nowadays. Thankfully Hotwire Turbo is back-end agnostic which means you can build really nice feeling front-ends with any tech stack with minimal JS. I'm really happy DHH pioneered this pattern with Turbolinks which evolved into something wonderful.
the_gastropod 3y ago
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...)
ecshafer 3y ago
Could you share some examples of this? I am a bit over >1 year with Rails and I don't see this to be the case. There is some "group think" perhaps, but every ecosystem has that (Whats the "pythonic" way or Java way to write x). I work at Shopify which uses Ruby and Rails extensively, and I don't think things have "gone off the rails". We use other technologies where appropriate, but for the core business logic cases, Rails is fantastic.
- ulizzle 3y ago
  You have to measure by time-to-market / team size. How much it costs to maintain the system, how long it takes to ship features, fix bugs, reach milestones, etc; which is something you can't say publicly, and even if the company did, it would be heavily doctored to make a good impression on stakeholders. That's why I think the argument is a weak appeal to authority. Throw enough money at a problem, and you can scale anything involving computers. Notice how expensive is Heroku. But you can't add more team members to a project and expect things to go faster, which is where the real problem with Rails lies.
  - jemmyw 3y ago
    I've worked at a number of places using Rails and places using other languages. I cannot square your argument with my experience. The place I currently work has a 10 year old Rails monolith, less than 50 developers (I joined at ~10 devs) and features are still shipped very quickly. I would say that the Rails framework is one aspect of several that has allowed the company to ship fast and be very profitable without having to grow the engineering team massively. I've worked places where we've made a complete mess out of Java or .NET code. You might be correct that there is a degree of group think within Rails developers, but that's actually a good thing because they don't deviate too far away from a set of conventions for writing their code, which causes less mess. And they at least know what a convention is and stick to it once you agree on it. At one point in my career I thought I had put Rails behind me because it's not that compatible with services that are supposed to be more scalable. However, this again goes against your argument, I saw just how much overhead was being generated by that kind of architecture. Yes you could have way more developers working on the product, but they weren't working on deliverable features, they were working on integrating with the rest of the system. I'm sure there are team scalable limits to Rails. I've noticed though that as our product has become more complex more of the code needs to be frontend in order to support that interface complexity and so perhaps that team limit can actually be stretched out a very long way. Caveats: I think Rails is good and I'm defending it because I think the argument made here is bunk, but I'm sure there are Rails codebases that are a complete mess. I've pointed out other languages where I've seen issues, but I've also seen great codebases in those languages, so it's not a knock against them in particular. I'm not opposed or for any particular architecture, my experience is just that something like Rails can get you started much faster and can scale much further than a subset of devs seem to think.
haolez 3y ago
Saying that dynamic languages are prone to make a mess is a kind of groupthink in itself.
tenderlove 3y ago
I hope that you'll watch the recording of the talk when it's released. The context of the "cliche" is with regard to the community, the framework, and why Eileen continues to remain on the core team. It's nothing to do with the design or functionality of the framework itself. :)

lawn 3y ago

Incidentally I feel Rust is the reverse Ruby: more work (sometimes much more work) up front, but the big payoff comes in the long run.

ulizzle 3y ago
Many typed languages are like that, but the big difference is that they admit the trade-off. In Ruby on Rails, dissent is a big taboo, so they blame the problems on the devs (the unwashed nameless masses) rather than tackle the problem itself. That's why you have all these different tools and concepts; since they try to sandpaper over all the magical complexity by adding more complexity, it becomes a no-true Scotsman trivia game. What trips me up tbh is how tech history repeats itself almost verbatim. The Smalltalk story is very similar but with a different cast.
- rileyphone 3y ago
  In what way is Smalltalk similar? Its main problem was that it stopped evolving.
  - namaria 3y ago
    All software suffers from this. The whole point of programmable computers is allowing systems of unbounded complexity. Every tooling discussion degenerates into "it's a foot gun" vs "you're holding it wrong". If you remove friction, people will build bigger foot guns. If you install too many guardrails, holding it right requires contortion. The point is not which set of tools you use. There is no substitute for understanding the problem domain, the tools at hand and the labor market you have access to. Everything has a cost, you can't get free advantages from some technical insight or another.
nickjj 3y ago
I think there's a large class of apps where you end up writing less than 30-50k lines of code and things aren't a problem in the end. I've built a video course platform now in Flask, Phoenix and Rails and I've built about 60% of the platform in all 3 tech stacks. The Rails app has ~7k lines of code (LOC count includes everything but tests), it's substantially less than the others. The Phoenix app was by far the worst of the 3 in terms of how much code I had to write and overall "difficulty" of the code. The Flask app sat somewhere in the middle, at times it made doing certain things easier and more efficient than Rails but if I had to rank overall developer happiness and how easy it was to do things it would be Rails > Flask > Phoenix where let's say Rails is a 8.5 in terms of happiness, Flask is a solid 7 and Phoenix was maybe a 4 or 5. This includes a number of real-time elements like having a persistent video player that survives across page navigations, notifications and comments being broadcast to all connected clients with authentication and more.
- uxcolumbo 3y ago
  Surprised about your score for Phoenix. What exactly were the painpoints? My impression was Elixir / Phoenix was ranking high in developer happiness.
  - nickjj 3y ago
    Developer happiness includes all facets of development IMO. The language, 3rd party packages, the overall ecosystem, the community, etc.. Elixir isn't really in the same ballpark as Python and Ruby for package support. Lots of 3rd party vendors don't have official SDKs for Elixir and having to recreate certain components of those SDKs manually can be very tricky. This is especially true for payment gateways like Stripe, Payal, Paddle and others since there's gory details about certain things aren't as easy as making an HTTP call with a token. So you end up having to recreate these things from scratch because most community versions are abandoned due to them being maintained by 1 or 2 people who stopped using it. Also, LiveView's APIs keep changing. The amount of churn was out of control for a few years where it felt like every few months you had to make drastic rewrites to keep up with it all. At the same time the docs are very minimal and community support through blog posts weren't there in the same way they are for Rails and Flask. It felt like you were on your own to solve everything in a fast moving world with an ever growing API. Then for the language, Elixir didn't click for me, even after writing 10k lines of code. I felt like I could get pretty far and understood enough to get most things done but I felt like I was getting stonewall'd quite frequently and couldn't solve certain basic problems after exhausting all pre-existing resources (my brain, docs, blog posts, open source projects, etc.). I don't feel I have this same issue in Python or Ruby. There's such a big community that nearly everything can be found, or at least get you to the point where you can apply something to your domain without asking in chat for help. A good example is https://github.com/josevalim/nested-map-reduce-traversal https://github.com/josevalim/nested-map-reduce-traversal which is something Jose and I worked on a few years ago. If he didn't step in and provide an example on how to do what's essentially a nested loop while modifying a counter in Elixir I would have had to stop developing my project. I still have to step back and spend a full 5 minutes trying to mentally parse his solution where as the Python and Ruby solutions are immediate with no effort. When trying to build a pretty big project, these routine blockers or having to spend 3 hours (or 3 days) down a rabbit hole vs just doing it in a few minutes make a big difference -- this is also after spending months learning the language and ecosystem already. You end up getting fatigued from having to build so many libraries to get to the point where you can work on your main's app goal and it's demoralizing getting hard blocked. There's also this pit in your stomach that's concerned at how quickly you can get stuck in a way that you can't self-resolve. When trying to build a business, these are all very dangerous things. You put all of that together and my happiness level for Elixir was kind of low. It's nothing personal, just my opinion. I think it has good ideas and concepts in places but it didn't feel like the juice was worth the squeeze for someone like me who didn't already have many years of functional programming experience beforehand. Flask and Rails are both fast enough where you can build a million dollar a year business on a single $40 / month server with tens of thousands of customers. You can still get p95+ <= 100ms response times from your back-end in this scenario and both tech stacks have a good story for using websockets nowadays. Thankfully Hotwire Turbo is back-end agnostic which means you can build really nice feeling front-ends with any tech stack with minimal JS. I'm really happy DHH pioneered this pattern with Turbolinks which evolved into something wonderful.

the_gastropod 3y ago

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...)

ecshafer 3y ago

Could you share some examples of this? I am a bit over >1 year with Rails and I don't see this to be the case. There is some "group think" perhaps, but every ecosystem has that (Whats the "pythonic" way or Java way to write x). I work at Shopify which uses Ruby and Rails extensively, and I don't think things have "gone off the rails". We use other technologies where appropriate, but for the core business logic cases, Rails is fantastic.

ulizzle 3y ago
You have to measure by time-to-market / team size. How much it costs to maintain the system, how long it takes to ship features, fix bugs, reach milestones, etc; which is something you can't say publicly, and even if the company did, it would be heavily doctored to make a good impression on stakeholders. That's why I think the argument is a weak appeal to authority. Throw enough money at a problem, and you can scale anything involving computers. Notice how expensive is Heroku. But you can't add more team members to a project and expect things to go faster, which is where the real problem with Rails lies.
- jemmyw 3y ago
  I've worked at a number of places using Rails and places using other languages. I cannot square your argument with my experience. The place I currently work has a 10 year old Rails monolith, less than 50 developers (I joined at ~10 devs) and features are still shipped very quickly. I would say that the Rails framework is one aspect of several that has allowed the company to ship fast and be very profitable without having to grow the engineering team massively. I've worked places where we've made a complete mess out of Java or .NET code. You might be correct that there is a degree of group think within Rails developers, but that's actually a good thing because they don't deviate too far away from a set of conventions for writing their code, which causes less mess. And they at least know what a convention is and stick to it once you agree on it. At one point in my career I thought I had put Rails behind me because it's not that compatible with services that are supposed to be more scalable. However, this again goes against your argument, I saw just how much overhead was being generated by that kind of architecture. Yes you could have way more developers working on the product, but they weren't working on deliverable features, they were working on integrating with the rest of the system. I'm sure there are team scalable limits to Rails. I've noticed though that as our product has become more complex more of the code needs to be frontend in order to support that interface complexity and so perhaps that team limit can actually be stretched out a very long way. Caveats: I think Rails is good and I'm defending it because I think the argument made here is bunk, but I'm sure there are Rails codebases that are a complete mess. I've pointed out other languages where I've seen issues, but I've also seen great codebases in those languages, so it's not a knock against them in particular. I'm not opposed or for any particular architecture, my experience is just that something like Rails can get you started much faster and can scale much further than a subset of devs seem to think.

haolez 3y ago

Saying that dynamic languages are prone to make a mess is a kind of groupthink in itself.

tenderlove 3y ago

I hope that you'll watch the recording of the talk when it's released. The context of the "cliche" is with regard to the community, the framework, and why Eileen continues to remain on the core team. It's nothing to do with the design or functionality of the framework itself. :)