5 ms·

Rails gives you so much out of the box that it's very tempting if your app lies in Rails' sweet spot. However I've found that as apps grow bigger and accumulat

Rails gives you so much out of the box that it's very tempting if your app lies in Rails' sweet spot. However I've found that as apps grow bigger and accumulate more complex business logic and data flows Rails codebases become increasingly difficult to manage.

megraf 5y ago
This is likely the organization of the project. What do your service objects look like? Domains? Repositories? DTO's? How do you organize them? How about adapters? There's some great pieces of literature out there about advanced ruby / rails - well worth the read!
- cageface 5y ago
  IMO it has mostly to do with lack of static type checking and null safety. I don't encounter the same issues in large codebases in languages like Swift and Typescript.
- Master_Odin 5y ago
  As someone who has started learning Ruby to contribute to one of my companies' repos and the amount of "magic" in Rails has been a big stumbling block for me compared to any other language I've worked in lately (JS/TS, PHP, Python).
  - cageface 5y ago
    One big problem with Rails code is that when you're looking at any particular block of code is very difficult to figure out the scope of variables. They can be coming from a base class, a mixin, some kind of plugin etc. And dev tools usually won't help you figure this out. This alone makes maintaining Rails code a lot harder than something like Node/TS where all your imports are explicit.
    - RileyJames 5y ago
      This I would definitely agree with. I’ve found this many times when jumping into a new repo to fix a bug.
- baash05 5y ago
  100% agree.. If the services/jobs are focused, then even massive projects can be held in your head. And these can be built out if they're not there, so they can be the road to recovery
midrus 5y ago
Bad news for you: as apps grow bigger, they become complex and difficult to maintain in every single platform or language.
notpachet 5y ago
Agreed. I feel like a big part of the disconnect between Ruby/Rails enthusiasts and Ruby/Rails detractors comes down to what kinds of projects are being worked on. (This is a frequent theme in HN discussions of various technologies, not just Ruby/Rails.) For scrappy MVP's, where the most important thing is to quickly find product fit, Rails is often a great choice. The problem comes when that codebase starts to mature: you look up one day and realize that it's no longer just you working in the codebase. The lack of language-level documentation makes it difficult to onboard new members to the team. A new developer is inspecting a method they're tasked with refactoring. It accepts an argument named "input". What the hell is an input? Is it a hash? Is it a class instance? Both? Something else entirely? Idiomatic Ruby/Rails makes it quite hard to intuit expected inputs/outputs. (Ironically the community also vocally disavows the use of comments, which would ameliorate that problem somewhat.) Meanwhile, "Undefined method `blah` on nil:NilClass" errors start to litter your logs to the point that developers become numb to them. Invariant violations that should have been caught upstream, at their point of inception, sneak all over your runtime and you waste valuable employee hours trying to identify their true source. And Ruby's poor story around async i/o ties your hands as your traffic patterns begin to require a more sophisticated request processing pattern than "receive request, block thread, return response." Phrases like "worker saturation" and "let's make it an async job" start to dominate your engineering retrospectives. These are just a few of the sharp edges that come from trying to scale Ruby. You may point to solutions to them, but they don't compare in elegance to working in a language that obviate those problems in the first place. And while it's very easy to start a project in Ruby and gain a quick initial burst of momentum, it's commensurately difficult to switch to a more mature language+framework when you realize that your engineering org is suffering from Ruby/Rails shortcomings. This is not a blanket indictment of Ruby/Rails -- just an acknowledgement that different languages and frameworks are better suited to certain types of problems. In my opinion, Ruby/Rails are very well suited for small projects with few maintainers, where the total surface area of the domain model is pretty small. Or quick MVP's where you have to deliver next week or die. But the dynamic duo are not well suited to the kinds of problems that start to emerge as those MVP's scale up in complexity/LOC/number of maintainers. It's a bit of a catch 22. People will point to the big companies running Ruby/Rails. But from having worked at one of them (Shopify), I can say that we were spending an inordinate amount of time trying to plaster over their shortcomings; I'd imagine this is also true of the other big companies that run on the same stack.

megraf 5y ago

This is likely the organization of the project. What do your service objects look like? Domains? Repositories? DTO's? How do you organize them? How about adapters? There's some great pieces of literature out there about advanced ruby / rails - well worth the read!

cageface 5y ago
IMO it has mostly to do with lack of static type checking and null safety. I don't encounter the same issues in large codebases in languages like Swift and Typescript.
Master_Odin 5y ago
As someone who has started learning Ruby to contribute to one of my companies' repos and the amount of "magic" in Rails has been a big stumbling block for me compared to any other language I've worked in lately (JS/TS, PHP, Python).
- cageface 5y ago
  One big problem with Rails code is that when you're looking at any particular block of code is very difficult to figure out the scope of variables. They can be coming from a base class, a mixin, some kind of plugin etc. And dev tools usually won't help you figure this out. This alone makes maintaining Rails code a lot harder than something like Node/TS where all your imports are explicit.
  - RileyJames 5y ago
    This I would definitely agree with. I’ve found this many times when jumping into a new repo to fix a bug.
baash05 5y ago
100% agree.. If the services/jobs are focused, then even massive projects can be held in your head. And these can be built out if they're not there, so they can be the road to recovery

midrus 5y ago

Bad news for you: as apps grow bigger, they become complex and difficult to maintain in every single platform or language.

notpachet 5y ago

Agreed. I feel like a big part of the disconnect between Ruby/Rails enthusiasts and Ruby/Rails detractors comes down to what kinds of projects are being worked on. (This is a frequent theme in HN discussions of various technologies, not just Ruby/Rails.) For scrappy MVP's, where the most important thing is to quickly find product fit, Rails is often a great choice. The problem comes when that codebase starts to mature: you look up one day and realize that it's no longer just you working in the codebase. The lack of language-level documentation makes it difficult to onboard new members to the team. A new developer is inspecting a method they're tasked with refactoring. It accepts an argument named "input". What the hell is an input? Is it a hash? Is it a class instance? Both? Something else entirely? Idiomatic Ruby/Rails makes it quite hard to intuit expected inputs/outputs. (Ironically the community also vocally disavows the use of comments, which would ameliorate that problem somewhat.) Meanwhile, "Undefined method `blah` on nil:NilClass" errors start to litter your logs to the point that developers become numb to them. Invariant violations that should have been caught upstream, at their point of inception, sneak all over your runtime and you waste valuable employee hours trying to identify their true source. And Ruby's poor story around async i/o ties your hands as your traffic patterns begin to require a more sophisticated request processing pattern than "receive request, block thread, return response." Phrases like "worker saturation" and "let's make it an async job" start to dominate your engineering retrospectives. These are just a few of the sharp edges that come from trying to scale Ruby. You may point to solutions to them, but they don't compare in elegance to working in a language that obviate those problems in the first place. And while it's very easy to start a project in Ruby and gain a quick initial burst of momentum, it's commensurately difficult to switch to a more mature language+framework when you realize that your engineering org is suffering from Ruby/Rails shortcomings. This is not a blanket indictment of Ruby/Rails -- just an acknowledgement that different languages and frameworks are better suited to certain types of problems. In my opinion, Ruby/Rails are very well suited for small projects with few maintainers, where the total surface area of the domain model is pretty small. Or quick MVP's where you have to deliver next week or die. But the dynamic duo are not well suited to the kinds of problems that start to emerge as those MVP's scale up in complexity/LOC/number of maintainers. It's a bit of a catch 22. People will point to the big companies running Ruby/Rails. But from having worked at one of them (Shopify), I can say that we were spending an inordinate amount of time trying to plaster over their shortcomings; I'd imagine this is also true of the other big companies that run on the same stack.