Rails usage is certainly dropping off a bit. The competition is improving.
I personally got tired of the monkey patching, ActiveRecord's proclivity towards n+1 queries, and complete lack of types / static analysis, among other things. Having to keep a mental model of the types of the entire project, and having to write tests around types takes up a significant amount of my headspace, energy, and time. The older a project gets, the more of a headache these things become. There is an element of "just write better code" to avoid these pitfalls, and that works to an extent, but the older I get the more I realize that the tooling does play a large role in the outcome.
I'm firmly in the static typing camp myself, but at the same time I think it's good that there's still a language that is unabashedly dynamically typed. Looking at Python, when you take a language that was originally designed around dynamic typing and then bolt static typing on top, the result is just awkward all around, and ends up being the worst of both worlds.
> "just write better code" to avoid these pitfalls
A lot of issues in and with Rails code leans heavily on this idea. It often comes in other flavors like "You can write rails apps that perform really well" or "Its perfectly doable to write a clean easy maintainable codebase in rails".
And is apparent in the "Provide sharp knives" doctrine as "And by capable, I mean knowledgeable enough to know when and how, accordingly to their context, they should use the different and sometimes dangerous tools in the drawers."
I really dislike this approach. I don't want something that is full of foot-guns and therefore requires me to recognise them when I lack all information to do so.
I've written terrible Rails apps, exactly because it allowed me to so, and I didn't know they would become terrible, until they were. I now recognise the (design) patterns that are foot-guns, I now know the tell-tales that show me where the sharp knives are dangerously placed. But then I get dropped into a Rails codebase that has seen 20+ developers coming and going over a decade, as the 21st developer, and I see it filled with these footguns and dangerously wielded "sharp knives". Often there's a lot of history apparent from these previous devs who saw this too and fixed some of it. But the overall state is still abysmal.
Sure, it's all these devs that made it abysmal. But the ecosystem, the framework and the language allowed, and sometimes even encouraged them to make it that.
The N+1 queries issue has been addressed in the latest ActiveRecord versions. If there's an N+1, you can set ActiveRecord to raise an error instead of making the N+1 query. Bullet gem, for years now, has also been able to catch the N+1 queries and let you choose how you want to act upon that.
It's true that monkey patching is a problem. I hear you. It's more and more problem of the past though. People realized it's too sharp of a knife and stopped doing that.
Rails has strict_loading now which eliminates the n+1 issue. Which kinda supports your position that tooling plays a large role. I was always very aware of the issue but framework support makes it 10x easier
I personally got tired of the monkey patching, ActiveRecord's proclivity towards n+1 queries, and complete lack of types / static analysis, among other things. Having to keep a mental model of the types of the entire project, and having to write tests around types takes up a significant amount of my headspace, energy, and time. The older a project gets, the more of a headache these things become. There is an element of "just write better code" to avoid these pitfalls, and that works to an extent, but the older I get the more I realize that the tooling does play a large role in the outcome.