[sb8244]

Yes, Rails helps developers make good upfront choices to the structuring of their application and database. The DB layer and structure is going to be a bottleneck well before the programming framework is (I think this is true in any framework). I enjoy that Rails makes it easy to do things like take care of N+1 queries, do associations correctly, etc. That isn't exclusive to Rails, but it is really good in Rails.

[mmartinson]

I think Rails helps developers make ok choices to the structuring of their application, particular if it's serving a domain that models easily into a fairly conventional RESTish-API relational data structure. The strongly-held conventions (in both framework and community) that position it so well for upfront productivity don't leave a ton of space for taking a proactive approach to managing complexity in a trickier domain.

Smart, experienced people can of course identify where the framework leaves off and build within the confines of Rails to get things done. But I wouldn't say that Rails makes it particularly easy to, for example, use a object-oriented approach the the model layer. ActiveRecord, with its lovely but dangerous APIs, really wants to be your everything class. Domain namespacing, while doable (you can do anything in Ruby), isn't particularly intuitive compared to other parts of the framework.

None of this is to say that Rails is a bad tool and I'm grateful for what it's provided (thank you OSS maintainers). It does, however, trade medium-term maintainability for the up-front productivity it offers, which could be totally fine, but for me doesn't feel like a great trade.

[sb8244]

A tool in the hands of an expert will be used differently than a non expert. The model layer that AR suggests might not be good for an expert, but it will certainly help a non expert build their app for some time without too severe of issues.

You are right that it's far from perfect and it really is a "be everything" ORM.