4 ms·

For my team, this article comes at some interesting timing, since we're bumping into some of the same issues with Rails. Rails is now a mature framework and pa

by lunaru 8y ago

For my team, this article comes at some interesting timing, since we're bumping into some of the same issues with Rails. Rails is now a mature framework and part of the problem is its lack of consideration for large existing codebases running in production. While there are nice tools to help migrate (e.g. rails:update) that hit surface issues, the deep problem is that there are a lot of decisions made going from version to version that are obviously unfriendly to established projects. e.g.: https://github.com/rails/rails/issues/27231 https://github.com/rails/rails/issues/27231 Additionally, there are a lot of gems that are losing momentum, which are near-core to Rails. e.g.: https://github.com/thiagopradi/octopus/issues/490 https://github.com/thiagopradi/octopus/issues/490. This is a side effect of the above issue, where the alternatives to Rails are taking a lot of the community away to focus on newer/shiner things. Fortunately, we have companies like GitHub and Shopify that are still very much invested in the success of the ecosystem. All that said, it's still a great framework to go from 0 to production with a new idea or project. Other ecosystems we're entrenched in (Node for example) have their share of issues as well, but we won't go into those.

lostapathy 8y ago
> art of the problem is its lack of consideration for large existing codebases running in production To be fair - this has gotten a lot better. Upgrading 2.3 -> 3.2 was terrible. 3.2 -> 4.0 was terrible. 4.0 -> 4.1 was rough. Since then, I've found the upgrades pretty easy - to the point I ran rails 5.2.0-rc's in production for a while. As you fairly note, a big problem is that related gems lose momentum and they don't get updated - which blocks other updates. On the flip side, they usually aren't that hard to update and submit a PR on, either. Even not having those patches merged quickly is not so bad in ruby - it's easy to tell bundler to look at your fork of a gem on github rather than pulling the upstream.
- bhaak 8y ago
  What was your problem with going from 3.2 to 4.0? I think the upgrade path from 2.3 being terrible is generally accepted as being true. But I don't remember any hard problems from 3.x onward. At least for Rails itself. Gems dependencies are another problem. Like at one project we had pains every time Rails upgraded their minor version because the previous devs thought using Squeel instead of the builtin ActiveRecord a good idea. Just for being able to write slightly "nicer" queries and now this is a major stopper for going to Rails 5.
  - lostapathy 8y ago
    It's been a while, honestly I'm not totally sure. Generally speaking at that job, though, we tended to not wean ourselves off the deprecated features - we'd use the extracted gem to keep the functionality going. Which works fine for one minor release, but doesn't work when you are 3 minor releases later. Strong parameters is one that hurt bad. We used the workaround gem to avoid that for a long time, and it just made it more painful when we had to get rid of it. I think generally there were a lot of related gems that were hard to get updated along the way from 3.2 to 4.0 as well. Seems like a fair amount of libraries were late to the 4.0 party, then jumped ahead to 4.1 or 4.2, and never really got ironed out well against 4.0, so you'd have goofy compatibility issues. Squeel was a related problem that was horribly painful to remove from that stack as well, I forgot about that.
byroot 8y ago
> part of the problem is its lack of consideration for large existing codebases running in production That's just untrue. Almost half of the Rails core team works at GitHub and Shopify which both have huge 10 years old codebases and I can tell you they take breaking changes very seriously.

by lunaru 8y ago

lostapathy 8y ago

> art of the problem is its lack of consideration for large existing codebases running in production To be fair - this has gotten a lot better. Upgrading 2.3 -> 3.2 was terrible. 3.2 -> 4.0 was terrible. 4.0 -> 4.1 was rough. Since then, I've found the upgrades pretty easy - to the point I ran rails 5.2.0-rc's in production for a while. As you fairly note, a big problem is that related gems lose momentum and they don't get updated - which blocks other updates. On the flip side, they usually aren't that hard to update and submit a PR on, either. Even not having those patches merged quickly is not so bad in ruby - it's easy to tell bundler to look at your fork of a gem on github rather than pulling the upstream.

bhaak 8y ago
What was your problem with going from 3.2 to 4.0? I think the upgrade path from 2.3 being terrible is generally accepted as being true. But I don't remember any hard problems from 3.x onward. At least for Rails itself. Gems dependencies are another problem. Like at one project we had pains every time Rails upgraded their minor version because the previous devs thought using Squeel instead of the builtin ActiveRecord a good idea. Just for being able to write slightly "nicer" queries and now this is a major stopper for going to Rails 5.
- lostapathy 8y ago
  It's been a while, honestly I'm not totally sure. Generally speaking at that job, though, we tended to not wean ourselves off the deprecated features - we'd use the extracted gem to keep the functionality going. Which works fine for one minor release, but doesn't work when you are 3 minor releases later. Strong parameters is one that hurt bad. We used the workaround gem to avoid that for a long time, and it just made it more painful when we had to get rid of it. I think generally there were a lot of related gems that were hard to get updated along the way from 3.2 to 4.0 as well. Seems like a fair amount of libraries were late to the 4.0 party, then jumped ahead to 4.1 or 4.2, and never really got ironed out well against 4.0, so you'd have goofy compatibility issues. Squeel was a related problem that was horribly painful to remove from that stack as well, I forgot about that.

byroot 8y ago

> part of the problem is its lack of consideration for large existing codebases running in production That's just untrue. Almost half of the Rails core team works at GitHub and Shopify which both have huge 10 years old codebases and I can tell you they take breaking changes very seriously.