Miss Dada  🏳️‍⚧️

It is fair to say that for me it is very disappointing that https://rubyonrails.org/doctrine/  says nothing about performance. Performance is not a priority for the doctrine. Consumers of Rails at scale have a very different take.

"Performance is secondary to developer happiness" is not the same as "we actively don't care about performance". Rails is a project run by volunteers and has limited resources. Y'all are talking like we're actively just ignoring performance, vs having to prioritize our time.

There are also plenty of people, yourself included, who have spent sustained effort improving Rails performance. The false dichotomy is really destructive to both causes, and create gridlock between perspectives that gets nothing done.

What's the point of rhetoric that convinces folks who want to improve developer ergonomics that their goals are in conflict with performance? What do you think will happen over the long haul if performance-minded folks act like the tradeoff is zero-sum?

It's funny that you bring this up, because we want a Merb style outcome here and that's what we are working toward. I honestly don't feel AR can be fixed because of the deep seated cultural issues of "developer happiness > everything else"

in other words, the only way to get the outcome you want is to build the (mostly compatible) alternative and push it forward.

I'd welcome a Rails-like Rails competitor. In the absence of a concrete alternative, the rhetoric is counterproductive (because it alienates developer ergonomics folks from folks who care about performance, turning a win-win situation into zero-sum)

It'd be an ActiveRecord alternative, not a full Rails alternative. Working title.. TurboRecord ;)