Not sure why you're downvoted either, it's a legit concern. One way to address it is by being very conservative and picky with gems. A good example is Hey's Gemfile (the app made by Rails creators): https://gist.github.com/dhh/782fb925b57450da28c1e15656779556. It's a good (albeit slightly outdated) example of not straying too far from defaults, while not reinventing the wheel either.

You have to be super careful with gems because every single one you add risks blocking you from updating rails. Resulting you either having to wait for them to get updated, or if they are abandoned, you have to remove them and rewrite all the code that depends on them. I've spent so long replacing all the code in our app which is built on abandoned gems.

True. I tend to stay away from gems that try to integrate into multiple parts of your app to provide some sort of comprehensive solution. The kinds of gems I recommend are: 1) libraries (you call into them when you need them) 2) mounted apps on a url, isolated from the rest of your app 3) generators (a nice example: https://github.com/lazaronixon/authentication-zero).

I agree you need to be careful to only add high quality gems - but that holds true for the deps for any project.

You can also fork/vendor the gem and fix it, vs rewriting the whole thing from scratch. If a gem is abandoned you don't need to nuke it - you just take ownership of the code. Essentially if you use a gem you are saying "this code is as good as our code" so just maintain it just like it is your code.

I've never had problems with upgrades, in fact the latest version of Rails make upgrading a breeze. What Rails app version are you trying to upgrade? Happy to help. Rails also has an upgrade guide that's quite good: https://guides.rubyonrails.org/upgrading_ruby_on_rails.html

And you can use https://railsdiff.org/ to check what you're missing in upgrade apps. Anything other thing that breaks would most like come from another gem, which doesn't make it Rails' fault or Ruby itself, in the case of Ruby, you can track everything to the source to fix it. Ruby keeps a change log diligently. Everything is trackable, at least in my experience.

I've upgraded our moderately sized app from 3 to 4 to 5 to 6. Haven't gotten to 7 yet. This is widely accepted to be one of the most painful parts of rails, so I'm surprised you haven't had a problem. Maybe you've only upgraded small apps, or maybe only upgrade very recent versions (they are getting better). There are whole consultancies dedicated just to this task. Github and Shopify post about dedicating whole teams and tools just to the task.

Even with very high test coverage on a large app it is a huge and high risk effort to upgrade - there are so many deprecations and unnecessary behavior changes. The `belongs_to` now validates presence was especially egregious and arbitrary. Of course you can turn it off with a variable - but now we have a rails app that is a mix if defaults from 4 different versions of rails.

This is because Rails does not have a strict backwards compatibility policy like many other frameworks. It's done on purpose to stay relevant, aka "Progress over stability".

https://rubyonrails.org/doctrine#progress-over-stability

That would be fine, if it was possible to actually work out what changes you need to make. But Rails will have breaking changes every release that aren't mentioned in the docs. I've spent around 200+ hours over the last year trying to update our app from 5.1 to 5.2. And it's not some kind of megaproject on the scale of Github, its an ordinary app around 10 years old.

Every single Rails update is extremely painful and issues will slip through every unit test and browser automation you can come up with. Stuff that would be trivially catchable with type checking.

I would say the most annoying bit is around javascript. For example I would like to move a rails 6.1 project to 7, and also replace webpacker with esbuild. I'm pretty sure I will just create a fresh 7 project and start copy pastaing files over, then do the javascript stuff delicately (the default javascript setup in rails 7 is also quite strange)

But upgrading pure API Rails projects is much less painful

The Webpacker removal in particular was a huge pain for me. I was deeply frustrated by DHH’s belief that the framework no longer needs to support TypeScript.

It's hard to counter "it sucks" and other rather vague points like the ones you've made.

> upgrading to newer versions of RoR sucks

This hasn't been my experience at all. Rails comes with a built-in tool that interactively helps you upgrade your app `rails app:update`. Even on a 300k+ line Rails app I work on, our last major Rails upgrade took a single engineer about a week to do. It could be better, but it's one of the easier frameworks to upgrade, in my experience.

> The more time I invest in trying to like RoR the more I end up having to fork gems to patch them because upgrades cannot be made smoothly

Isn't this the case generally? Dependencies are liabilities. Not sure why this is a problem with Rails?!

> It so easily integrates ActiveRecord, and heavily encourages it, that when you want to pull out of using it it’s a huge pain.

ActiveRecord is a central component of the Rails framework. Why would they encourage you to use an alternative?

> Test suite combines unit and integration testing.

I think it's first important to state upfront: there is no single canonical definition of "unit" or "integration" tests. I assume your point is that the standard unit test examples in Rails hit the database? That being bad is, like, your opinion, man. And you totally can decide to not design things that way.