6 ms·

I spend a lot of time each year evaluating frameworks for our clients and their projects, and I keep on coming back to rails. > Does it turn into unmaintainabl

by wkirby 2y ago

I spend a lot of time each year evaluating frameworks for our clients and their projects, and I keep on coming back to rails. > Does it turn into unmaintainable spaghetti code after a while? Only if you let it. It's typically caused by developers, not programming languages or frameworks. After running a number of rails applications in production for going on a decade, this is really hard, and I find it to be one place where rails (really ruby) doesn't help much. Of all the languages we work in (and it's quite a few), ruby has the worst support for modern language tools: the LSP implementations are weak, and don't play well with containerized development environments. Typing efforts are fractured, and the official way is... well.. it's bad. This is exacerbated by ruby's tendencies towards "fluent" interfaces, which is actually code for lots of methods that take undocumented hashes of arguments --- and hash access with strings and symbols? nightmare fuel. But I still come back to rails. It's productive, it's fast enough, it scales just fine, and perhaps most importantly there's a "right" way to do just about everything your web application will ever need to do: background jobs, websockets, read-only database replicas. All in all, its still my recommendation for new web projects going into 2025.

sodapopcan 2y ago
> and perhaps most importantly there's a "right" way to do just about everything your web application will ever need to do A good chunk of chaos in Rails apps is caused by people who either insist they know better than the out-of-the-box solutions, or they “just prefer it my way.”
- cpursley 2y ago
  The biggest issues in Rails come from trying to do things with the ORM that should be done in the database.
  - mehal 2y ago
    Strongly agree to this. Rails developers for some reason just abandoning any work in database and tend to work with data in ruby env
    - cpursley 2y ago
      Yep, I'm a big fan of building views in postgres and just hitting those with the ORM. I don't even use the join syntax in my ORM (Ecto) - if I need a join, I use a view.
      - arcanemachiner 2y ago
        Interesting. Does Ecto have any syntax that supports this behavior? Or do you just use raw SQL for this?
        cpursley 2y ago
        You just treat a view the same way as a table with Ecto.
  - PittleyDunkin 2y ago
    Even as a bonafide activerecord hater, this sentiment doesn't make much sense to me. The ORM is like 70% of what makes rails fast to develop with, which is the entire reason to use rails in the first place. Everything from routes to rendering to form validation is tightly integrated around object lifecycles. If you get rid of that there's not much benefit to use rails (or in fact ruby) at all.
    - randomdata 2y ago
      Wouldn't you say you are a bonafide activerecord hater because of those same issues? I don't expect you hate it because your lost love interest shares the AR initials. ActiveRecord can both offer fast development and create issues (especially those that only come to bite you later). It exists in a multi-faceted environment. Tradeoffs, as always.
      - PittleyDunkin 2y ago
        Yes, I think it generally makes rails much more difficult to scale than it has to be, much more difficult to test, and more difficult to verify changes are "safe". I certainly agree with the commentary on tradeoffs, though, and I stand by my comment that AR is a big part of why Rails is such a massive success.
        randomdata 2y ago
        > I stand by my comment that AR is a big part of why Rails is such a massive success. I think most would agree. It is the "doesn't make much sense" part that we're discussing, though. How does it not make sense when you seem to have the same opinion of it? It seems, as an onlooker, that it makes perfect sense to you.
        PittleyDunkin 2y ago
        > How does it not make sense when you seem to have the same opinion of it? Well, what remains of Rails or of ActiveRecord once you remove the part that's done outside the database? It just seemed like a very shallow view of what rails is.
  - rco8786 2y ago
    I think historically that's probably right, but something that has gotten much better with time. Previously, ActiveRecord gave newer programmers a legible, fluent interface to the database in a language they already knew. So instead of learning SQL, we abused the heck out of AR. I think that the industry, and rails itself, has matured since then and I see a lot less of this nowadays.
  - deleted 2y ago
    [deleted]
- PittleyDunkin 2y ago
  the extensive use of method_missing doesn't help either.
  - semiquaver 2y ago
    Can you point to any substantial places in rails where method_missing is actually used? The only place I’m aware of is dynamic finder methods like find_by_foo, which IIRC were removed years ago. Most of the more magical ORM stuff is implemented using boot-time metaprogramming things like define_method.
    - PittleyDunkin 2y ago
      I'll take your word for it—I'm currently blessed by working outside of the rails ecosystem so my knowledge is likely out of date. EDIT: I'm not bothered by this, but this is a very odd comment to downvote. What on earth is so offensive or distracting about saying someone else is likely more knowledgable than you are? Very confusing.
  - rco8786 2y ago
    That's been gone since Rails 4 or 5 (we're on 8 now)
runjake 2y ago
> Does it turn into unmaintainable spaghetti code after a while? I say this genuinely enjoying JavaScript programming, but my mind immediately jumped to "as opposed to immediately, like most JS frameworks?"
- deleted 2y ago
  [deleted]
- wkirby 2y ago
  I do find 6-month old typescript to be easier to return to than 6-month old ruby — same goes for most typed languages. The reality is, though, that the benefit of strong types isn't so much in giving you compile time errors as it is forcing the devs to document their method signatures.
  - chris12321 2y ago
    I find that a 6-month-old JS project will often not even boot since its exhaustive dependency list will be out of date and now mutually incompatible. You have to feed a JS project with updates every couple of hours, or it will die like a Tamagotchi.
    - shepherdjerred 2y ago
      I've seen comments like this almost daily this week. Does HN not use lockfiles or something? Your node/npm project will work just fine if you use the same version of node/npm and have a lockfile. Maybe you're using npm i (which can upgrade dependencies in some cases) instead of npm ci [0] (which always uses the lockfile dependencies). In any case, this is a general problem of package managers and has nothing to do with the language. You'll need something similar if you're using _any_ external dependency in Rust, Python, Go, etc. [0]: https://docs.npmjs.com/cli/v10/commands/npm-ci https://docs.npmjs.com/cli/v10/commands/npm-ci
skipants 2y ago
I agree with you on all your points but I came to the conclusion that I would _not_ start a new app in Rails for those reasons. I've spent my whole career on Rails and I think it's amazing when starting small but mature applications are a nightmare to refactor. Every monolith Rails app feels like it hits tech bankruptcy after ~5 years.
- codesnik 2y ago
  "tech bankruptcy"! this is a VERY strong sentiment. First of all, I've never seen a rails-based company which has it problems from tech department, and not from product market fit or whatever, and that's in a 18 year carreer. I'm singlehandedly refactoring right now a 10-yearish rails app which had a period of neglect and bad contractors who broke every single test, and it is still very much manageable.
  - stouset 2y ago
    > I've never seen a rails-based company which has it problems from tech department I've been using Rails since 1.0, owe much of my career to it, and still think it's an incredible framework that I love using. But I have seen plenty of startups—mostly filled with junior developers—who don't have the maturity and experience to avoid some really bad ideas absolutely wall themselves into a corner. Thankfully the worst of this was in the Ruby 1.8 and Rails 2.3 era, but it still happens today. A lot of the issue is the tendency that Ruby libraries have toward exposing internal details that end up getting relied upon (Hyrum's law in action).
    - lcnPylGDnU4H9OF 2y ago
      Hadn't heard of Hyrum's law before. https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. (There's something about the way people manage to phrase these that I really enjoy. Something about the succinct and clear expression of an idea that's otherwise really fuzzy in my head.) It's interesting to think about the implementation being necessarily coupled with the interface. In some context that's obvious, but the idea that another implementation can't be freely swapped in -- because nuanced behavior (sometimes called a bug) in the original implementation is still expected -- is one I hadn't, as such, thought much about before.
JohnBooty 2y ago
This is exacerbated by ruby's tendencies towards "fluent" interfaces, which is actually code for lots of methods that take undocumented hashes of arguments Well, I hate this too. I've been away from Ruby for 18 months but my impression was that the community has been moving away from that for a long time and toward keyword args (or whatever they're called, I forget) and hash access with strings and symbols? nightmare fuel. What's the alternative? I like hash access with symbols. Prevents typos and the string values for the hashes are interned AFAIK. After running a number of rails applications in production for going on a decade, this is really hard, I don't feel that Ruby is worse than other languages I've used extensively (Ruby, Python, JS, C#) in this regard. The issue is one's apps dependency graph. You keep dependencies flowing in one direction. Or you do not and you get spaghetti. I have not worked with languages that are really better or worse at this. To take the example of a typical Rails app: it's very easy to add code to your Model A that depends on Models B, C, and D. Do that in a few models and...boom! spaghetti! Rails does not discourage or warn about this in the slightest. It's relatively easy to avoid: have a rule that "no model can contain a reference to another model. if you have to do a thing that involves two models, put it in a service class" or some such. Of course, nobody ever does this. Are there languages and frameworks that encourage/enforce The Right Thing in a more active way?
- wkirby 2y ago
  > Are there languages and frameworks that encourage/enforce The Right Thing in a more active way? I don't think so, as evidenced by the fact that I'm still so pro Rails after a decade of doing this. But that doesn't mean we can't be vocal about the things that still suck. > I like hash access with symbols Oh, I vastly prefer symbol access to string access, but this is really a ruby problem, not a rails problem. The fact that I can pass `{ "foo" => "bar" }` and `{ foo: "bar" }`, and my method has to either call `with_indifferent_access` or _strictly_ enforce being called with one of the two access types is a huge footgun, because improper access doesn't result in an error, it just results in a `nil`.
bhaak 2y ago
> Typing efforts are fractured, and the official way is... well.. it's bad. Official way? I thought there is none. As long as there is no support for gradual typing in the core language it will never be used outside of niche programming. And then I have a hard time imagining that Rails would use it anyway. Unless the performance boost would be tremendous.
- rco8786 2y ago
  https://github.com/ruby/rbs https://github.com/ruby/rbs is the "officially supported" one. It's terrible, as is Sorbet. No offense to anyone involved with either of the projects, they just miss the mark in pretty fundamental ways.
- wkirby 2y ago
  Type definitions were introduced in Ruby 3. I personally think they are terrible --- primarily because they exist in sibling type files. They are arduous to write, don't have great tooling support, and don't feel like a part of the language at all.
bradgessler 2y ago
> This is exacerbated by ruby's tendencies towards "fluent" interfaces, which is actually code for lots of methods that take undocumented hashes of arguments --- and hash access with strings and symbols? nightmare fuel. Keyword arguments and pattern matching have improved this quite a bit, but not everybody is using it yet. I'm not sure how much Rails is using it either, which doesn't help. It's def a dicey situation, but improving.
Pxtl 2y ago
In my experience, it's rarely the serving language that causes the hellscape of spaghetti. Possibly the SQL if you've got one of those weird luddites who wants all the business in stored procs running the project. It's the JS+CSS that does it.
jimbob45 2y ago
May I please ask what set Rails ahead of the .NET and Spring frameworks?
- tmnvix 2y ago
  Avoidance of a proprietary MS stack is why I went with Django 15 years ago. I imagine this played a large part in the appeal of Rails at the time too.

by wkirby 2y ago

sodapopcan 2y ago

> and perhaps most importantly there's a "right" way to do just about everything your web application will ever need to do A good chunk of chaos in Rails apps is caused by people who either insist they know better than the out-of-the-box solutions, or they “just prefer it my way.”

cpursley 2y ago
The biggest issues in Rails come from trying to do things with the ORM that should be done in the database.
- mehal 2y ago
  Strongly agree to this. Rails developers for some reason just abandoning any work in database and tend to work with data in ruby env
  - cpursley 2y ago
    Yep, I'm a big fan of building views in postgres and just hitting those with the ORM. I don't even use the join syntax in my ORM (Ecto) - if I need a join, I use a view.
    - arcanemachiner 2y ago
      Interesting. Does Ecto have any syntax that supports this behavior? Or do you just use raw SQL for this?
      - cpursley 2y ago
        You just treat a view the same way as a table with Ecto.
- PittleyDunkin 2y ago
  Even as a bonafide activerecord hater, this sentiment doesn't make much sense to me. The ORM is like 70% of what makes rails fast to develop with, which is the entire reason to use rails in the first place. Everything from routes to rendering to form validation is tightly integrated around object lifecycles. If you get rid of that there's not much benefit to use rails (or in fact ruby) at all.
  - randomdata 2y ago
    Wouldn't you say you are a bonafide activerecord hater because of those same issues? I don't expect you hate it because your lost love interest shares the AR initials. ActiveRecord can both offer fast development and create issues (especially those that only come to bite you later). It exists in a multi-faceted environment. Tradeoffs, as always.
    - PittleyDunkin 2y ago
      Yes, I think it generally makes rails much more difficult to scale than it has to be, much more difficult to test, and more difficult to verify changes are "safe". I certainly agree with the commentary on tradeoffs, though, and I stand by my comment that AR is a big part of why Rails is such a massive success.
      - randomdata 2y ago
        > I stand by my comment that AR is a big part of why Rails is such a massive success. I think most would agree. It is the "doesn't make much sense" part that we're discussing, though. How does it not make sense when you seem to have the same opinion of it? It seems, as an onlooker, that it makes perfect sense to you.
        PittleyDunkin 2y ago
        > How does it not make sense when you seem to have the same opinion of it? Well, what remains of Rails or of ActiveRecord once you remove the part that's done outside the database? It just seemed like a very shallow view of what rails is.
- rco8786 2y ago
  I think historically that's probably right, but something that has gotten much better with time. Previously, ActiveRecord gave newer programmers a legible, fluent interface to the database in a language they already knew. So instead of learning SQL, we abused the heck out of AR. I think that the industry, and rails itself, has matured since then and I see a lot less of this nowadays.
- deleted 2y ago
  [deleted]
PittleyDunkin 2y ago
the extensive use of method_missing doesn't help either.
- semiquaver 2y ago
  Can you point to any substantial places in rails where method_missing is actually used? The only place I’m aware of is dynamic finder methods like find_by_foo, which IIRC were removed years ago. Most of the more magical ORM stuff is implemented using boot-time metaprogramming things like define_method.
  - PittleyDunkin 2y ago
    I'll take your word for it—I'm currently blessed by working outside of the rails ecosystem so my knowledge is likely out of date. EDIT: I'm not bothered by this, but this is a very odd comment to downvote. What on earth is so offensive or distracting about saying someone else is likely more knowledgable than you are? Very confusing.
- rco8786 2y ago
  That's been gone since Rails 4 or 5 (we're on 8 now)

runjake 2y ago

> Does it turn into unmaintainable spaghetti code after a while? I say this genuinely enjoying JavaScript programming, but my mind immediately jumped to "as opposed to immediately, like most JS frameworks?"

deleted 2y ago
[deleted]
wkirby 2y ago
I do find 6-month old typescript to be easier to return to than 6-month old ruby — same goes for most typed languages. The reality is, though, that the benefit of strong types isn't so much in giving you compile time errors as it is forcing the devs to document their method signatures.
- chris12321 2y ago
  I find that a 6-month-old JS project will often not even boot since its exhaustive dependency list will be out of date and now mutually incompatible. You have to feed a JS project with updates every couple of hours, or it will die like a Tamagotchi.
  - shepherdjerred 2y ago
    I've seen comments like this almost daily this week. Does HN not use lockfiles or something? Your node/npm project will work just fine if you use the same version of node/npm and have a lockfile. Maybe you're using npm i (which can upgrade dependencies in some cases) instead of npm ci [0] (which always uses the lockfile dependencies). In any case, this is a general problem of package managers and has nothing to do with the language. You'll need something similar if you're using _any_ external dependency in Rust, Python, Go, etc. [0]: https://docs.npmjs.com/cli/v10/commands/npm-ci https://docs.npmjs.com/cli/v10/commands/npm-ci

skipants 2y ago

I agree with you on all your points but I came to the conclusion that I would _not_ start a new app in Rails for those reasons. I've spent my whole career on Rails and I think it's amazing when starting small but mature applications are a nightmare to refactor. Every monolith Rails app feels like it hits tech bankruptcy after ~5 years.

codesnik 2y ago
"tech bankruptcy"! this is a VERY strong sentiment. First of all, I've never seen a rails-based company which has it problems from tech department, and not from product market fit or whatever, and that's in a 18 year carreer. I'm singlehandedly refactoring right now a 10-yearish rails app which had a period of neglect and bad contractors who broke every single test, and it is still very much manageable.
- stouset 2y ago
  > I've never seen a rails-based company which has it problems from tech department I've been using Rails since 1.0, owe much of my career to it, and still think it's an incredible framework that I love using. But I have seen plenty of startups—mostly filled with junior developers—who don't have the maturity and experience to avoid some really bad ideas absolutely wall themselves into a corner. Thankfully the worst of this was in the Ruby 1.8 and Rails 2.3 era, but it still happens today. A lot of the issue is the tendency that Ruby libraries have toward exposing internal details that end up getting relied upon (Hyrum's law in action).
  - lcnPylGDnU4H9OF 2y ago
    Hadn't heard of Hyrum's law before. https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. (There's something about the way people manage to phrase these that I really enjoy. Something about the succinct and clear expression of an idea that's otherwise really fuzzy in my head.) It's interesting to think about the implementation being necessarily coupled with the interface. In some context that's obvious, but the idea that another implementation can't be freely swapped in -- because nuanced behavior (sometimes called a bug) in the original implementation is still expected -- is one I hadn't, as such, thought much about before.

JohnBooty 2y ago

This is exacerbated by ruby's tendencies towards "fluent" interfaces, which is actually code for lots of methods that take undocumented hashes of arguments Well, I hate this too. I've been away from Ruby for 18 months but my impression was that the community has been moving away from that for a long time and toward keyword args (or whatever they're called, I forget) and hash access with strings and symbols? nightmare fuel. What's the alternative? I like hash access with symbols. Prevents typos and the string values for the hashes are interned AFAIK. After running a number of rails applications in production for going on a decade, this is really hard, I don't feel that Ruby is worse than other languages I've used extensively (Ruby, Python, JS, C#) in this regard. The issue is one's apps dependency graph. You keep dependencies flowing in one direction. Or you do not and you get spaghetti. I have not worked with languages that are really better or worse at this. To take the example of a typical Rails app: it's very easy to add code to your Model A that depends on Models B, C, and D. Do that in a few models and...boom! spaghetti! Rails does not discourage or warn about this in the slightest. It's relatively easy to avoid: have a rule that "no model can contain a reference to another model. if you have to do a thing that involves two models, put it in a service class" or some such. Of course, nobody ever does this. Are there languages and frameworks that encourage/enforce The Right Thing in a more active way?

wkirby 2y ago
> Are there languages and frameworks that encourage/enforce The Right Thing in a more active way? I don't think so, as evidenced by the fact that I'm still so pro Rails after a decade of doing this. But that doesn't mean we can't be vocal about the things that still suck. > I like hash access with symbols Oh, I vastly prefer symbol access to string access, but this is really a ruby problem, not a rails problem. The fact that I can pass `{ "foo" => "bar" }` and `{ foo: "bar" }`, and my method has to either call `with_indifferent_access` or _strictly_ enforce being called with one of the two access types is a huge footgun, because improper access doesn't result in an error, it just results in a `nil`.

bhaak 2y ago

> Typing efforts are fractured, and the official way is... well.. it's bad. Official way? I thought there is none. As long as there is no support for gradual typing in the core language it will never be used outside of niche programming. And then I have a hard time imagining that Rails would use it anyway. Unless the performance boost would be tremendous.

rco8786 2y ago
https://github.com/ruby/rbs https://github.com/ruby/rbs is the "officially supported" one. It's terrible, as is Sorbet. No offense to anyone involved with either of the projects, they just miss the mark in pretty fundamental ways.
wkirby 2y ago
Type definitions were introduced in Ruby 3. I personally think they are terrible --- primarily because they exist in sibling type files. They are arduous to write, don't have great tooling support, and don't feel like a part of the language at all.

bradgessler 2y ago

> This is exacerbated by ruby's tendencies towards "fluent" interfaces, which is actually code for lots of methods that take undocumented hashes of arguments --- and hash access with strings and symbols? nightmare fuel. Keyword arguments and pattern matching have improved this quite a bit, but not everybody is using it yet. I'm not sure how much Rails is using it either, which doesn't help. It's def a dicey situation, but improving.

Pxtl 2y ago

In my experience, it's rarely the serving language that causes the hellscape of spaghetti. Possibly the SQL if you've got one of those weird luddites who wants all the business in stored procs running the project. It's the JS+CSS that does it.

jimbob45 2y ago

May I please ask what set Rails ahead of the .NET and Spring frameworks?

tmnvix 2y ago
Avoidance of a proprietary MS stack is why I went with Django 15 years ago. I imagine this played a large part in the appeal of Rails at the time too.