3 ms·

Agreed. I've done a lot of Rails over the years, and concluded that, except in the hands of a stable and incredibly disciplined, talented, and knowledgable-abou

Agreed. I've done a lot of Rails over the years, and concluded that, except in the hands of a stable and incredibly disciplined, talented, and knowledgable-about-Rails team, it borders on being write-only. Ruby's fun to write but I hope never to onboard to a Rails codebase again. I think the vast majority of the ones in the wild are... not great, to put it mildly.

FigurativeVoid 5y ago
This is probably closer to the real reason that we have had so much fun. I am not particularly senior, and I was wholly new to ruby, but the senior engineers that joined are the "incredibly disciplined, talented, and knowledgable-about-Rails team." It's not just the framework, but the fact that have proper tests, architecture, and CI/CD.
jrochkind1 5y ago
I am curious what codebases you have encountered in the wild (with similar age and turnover to those ruby ones) that are great and easy to work with! Have you found this correlates to other platforms better? I feel like in my career, across many different languages and platforms, "legacy" codebases (ie, any codebase that pre-dates me and is a non-trivial amount of code) are uniformly "not great to put it mildly".
- handrous 5y ago
  Of course most codebases are shit, but it matters a lot more when a Rails codebase is shit than in many other languages/frameworks. The reasons are mainly: 1) The amount of "magic" available and how much it's used—in low-magic scripting languages or frameworks, you can at least grep to find definitions, even if better code navigation tools aren't available. The more often the answer the "wtf is this?" can't be known for-sure until runtime, the harder it is to find your way around, and the more memorization you have to do. Rails and its ecosystem are very high-magic, even more so than something like the roughly-comparable Django. It can be annoying to even figure out which gem defines a given symbol, in a given context. 2) The level of reliance on tests to keep things from falling completely apart. Tests are generally good things, of course, regardless of language, but a poorly-maintained test suite in a Rails codebase is a far more grave problem than it would be in, say, a Go or Typescript codebase (yes, it's mainly the static typing that makes the difference). That is, keeping the codebase viable requires more active attention and work. This is exacerbated by Rails being a common choice for bootstrapping startups (the library ecosystem, especially Devise, which might be single-handedly the main reason Rails wins as many "what should we use?" discussions as it still does, is a pretty damn strong argument in its favor) and bootstrapping startups having a tendency to go through multiple teams in short order (contractors and external dev teams being common, both in the early days and in the somewhat-later, very common, "oh god the cut-rate shop we got to build this fucked it up, please save us" phase) means that a whole lot of live Rails codebases have been treated very poorly, and that, for the above reasons, a Rails codebase that's been treated very poorly is a special kind of hell.
  - jrochkind1 5y ago
    I am genuinely curious, in your experience of working with "legacy" projects, what platforms/languages, with codebases of approximately the same age/turnover/type-of-project as the Rails ones, were significantly "less shit"? You didn't answer that part! Or, I guess, you implied Django?
    - handrous 5y ago
      I did cover that—it's irrelevant, because Rails in particular is much worse, at similar levels of neglect or incompetence, than lots of other frameworks+languages. It's a joy to build with from scratch, and it's fine as long as your team is steady, disciplined, quite good, and mainly focused on your Rails codebase (that is, it doesn't go for long stretches without eyeballs on it and effort going into keeping it up). Deviate from that ideal state and it starts to turn awful in a hurry—and of course other languages and frameworks do, too, but the curve for Rails codebases that fall of that ideal plateau of quality is much harsher than most.
      - jrochkind1 5y ago
        So you have worked with legacy codebases at similar levels of age and project type that haven't been as bad as the Rails ones? I am just curious to know what they are! I don't understand why you don't want to tell me, but ok, the end!
        handrous 5y ago
        All proprietary ones, but yes, of course. I don't know what you think I'm trying to avoid telling you—I've worked on a lot of codebases in a lot of languages for a lot of different platforms over ~20 years, and repeated exposure to Rails codebases (maybe half a dozen of them?) has yielded the observations already posted: that they are like closed-ecosystem terrariums, which are beautiful until something goes slightly wrong, and then everything good about them withers and dies in short order.

FigurativeVoid 5y ago

This is probably closer to the real reason that we have had so much fun. I am not particularly senior, and I was wholly new to ruby, but the senior engineers that joined are the "incredibly disciplined, talented, and knowledgable-about-Rails team." It's not just the framework, but the fact that have proper tests, architecture, and CI/CD.

jrochkind1 5y ago

I am curious what codebases you have encountered in the wild (with similar age and turnover to those ruby ones) that are great and easy to work with! Have you found this correlates to other platforms better? I feel like in my career, across many different languages and platforms, "legacy" codebases (ie, any codebase that pre-dates me and is a non-trivial amount of code) are uniformly "not great to put it mildly".

handrous 5y ago
Of course most codebases are shit, but it matters a lot more when a Rails codebase is shit than in many other languages/frameworks. The reasons are mainly: 1) The amount of "magic" available and how much it's used—in low-magic scripting languages or frameworks, you can at least grep to find definitions, even if better code navigation tools aren't available. The more often the answer the "wtf is this?" can't be known for-sure until runtime, the harder it is to find your way around, and the more memorization you have to do. Rails and its ecosystem are very high-magic, even more so than something like the roughly-comparable Django. It can be annoying to even figure out which gem defines a given symbol, in a given context. 2) The level of reliance on tests to keep things from falling completely apart. Tests are generally good things, of course, regardless of language, but a poorly-maintained test suite in a Rails codebase is a far more grave problem than it would be in, say, a Go or Typescript codebase (yes, it's mainly the static typing that makes the difference). That is, keeping the codebase viable requires more active attention and work. This is exacerbated by Rails being a common choice for bootstrapping startups (the library ecosystem, especially Devise, which might be single-handedly the main reason Rails wins as many "what should we use?" discussions as it still does, is a pretty damn strong argument in its favor) and bootstrapping startups having a tendency to go through multiple teams in short order (contractors and external dev teams being common, both in the early days and in the somewhat-later, very common, "oh god the cut-rate shop we got to build this fucked it up, please save us" phase) means that a whole lot of live Rails codebases have been treated very poorly, and that, for the above reasons, a Rails codebase that's been treated very poorly is a special kind of hell.
- jrochkind1 5y ago
  I am genuinely curious, in your experience of working with "legacy" projects, what platforms/languages, with codebases of approximately the same age/turnover/type-of-project as the Rails ones, were significantly "less shit"? You didn't answer that part! Or, I guess, you implied Django?
  - handrous 5y ago
    I did cover that—it's irrelevant, because Rails in particular is much worse, at similar levels of neglect or incompetence, than lots of other frameworks+languages. It's a joy to build with from scratch, and it's fine as long as your team is steady, disciplined, quite good, and mainly focused on your Rails codebase (that is, it doesn't go for long stretches without eyeballs on it and effort going into keeping it up). Deviate from that ideal state and it starts to turn awful in a hurry—and of course other languages and frameworks do, too, but the curve for Rails codebases that fall of that ideal plateau of quality is much harsher than most.
    - jrochkind1 5y ago
      So you have worked with legacy codebases at similar levels of age and project type that haven't been as bad as the Rails ones? I am just curious to know what they are! I don't understand why you don't want to tell me, but ok, the end!
      - handrous 5y ago
        All proprietary ones, but yes, of course. I don't know what you think I'm trying to avoid telling you—I've worked on a lot of codebases in a lot of languages for a lot of different platforms over ~20 years, and repeated exposure to Rails codebases (maybe half a dozen of them?) has yielded the observations already posted: that they are like closed-ecosystem terrariums, which are beautiful until something goes slightly wrong, and then everything good about them withers and dies in short order.