[resonious]

Good stuff but the `size`, `count`, `length` section just intensifies my dislike for ORMs. ORMs bury all of the SQL, just for devs to dig it back up when they realize it's important for performance. Now you have to be a SQL expert and an ActiveRecord expert.

[vemv]

This particular is easy to pick up and remember.

Also, a proficient developer looks at the SQL logs anyway as they develop a given feature.

Rails' flavor of ORM is particularly composable and transparent - you can easily mix/match it with vanilla SQL.

[resonious]

I guess this is a fair point. It is easy to use SQL with AR. But when you do so, you get lambasted in code review by people saying "you can generate this same SQL with this arcane Arel incantation!!". But that is certainly a culture problem and not a technical one!

[andatki]

I tend to agree as a SQL enthusiast. However I have yet to see a Rails team that doesn’t use Active Record or writes much SQL directly, or by default, across 100s of apps. I’m sure it happens but in my experience it’s rare.

This is a place where I think tools like Rubocop help. They can be configured to point out method swaps like this (size over count) automatically which is a relatively low effort task to change the code.

With those rules/linting in place, you aren’t throwing out the benefits of AR (ORM), and hopefully leveraging their useful methods like these that help avoid unnecessary queries.

[ckdot2]

Please, please don't mix up ORMs with ActiveRecords. ActiveRecords are one way to implement an ORM, but it's not the only way. I think many say they hate ORMs when they actually mean ActiveRecords. For bigger projects ActiveRecords suck, yes. But also you need to have some database layer logic which most likely does some Object & Relation Mapping (ORM).

[phendrenad2]

I disagree. POROs are the way to go.

[allknowingfrog]

I don't want to live in a world where I can't pop into a Rails console and run something like `Foo.joins(:bars).any?`.

More concretely, performance is on my list of "good problems to have". Businesses die in the time it takes to write raw SQL.

[mrtesthah]

sometimes performance can be so bad that the business can’t launch in the first place.

[allknowingfrog]

Oh sure, it's all about knowing your requirements. I write raw SQL when performance or complexity call for it. My intention was to argue that both have merits, not that ORMs are the one true solution.