The thing I always liked about linq was it’s lazy evaluation. You could write simple selects on your data model and join and filter in the service. Allowing unit tests that operated on the joins.
I’m yet to find a better way to write crud apps than that pattern.
After days of fumbling in the dark you finally isolate the problematic query, post it like "guys I found it," and still nobody speaks up. So you hack the ORM to attach tracebacks as comments to each query, retest everything, and finally git-blame your way to somebody who owns that bit of code and they're always like "wait, the ORM did WHAT?"
Sadly the choice of sql tends to make underlying framework very complicated and sometimes incapable.
Some things got easier to express with SQL after Json_agg in postgres became a thing (now you can do multi-depth relations without blowing up the result table with Cartesian product) but it's still massive pain in the ass and Json agg has performance overhead too.
Right, most ORM tools give an escape hatch to execute raw SQL queries. However, even though SQL is turing complete, it's not a great language for retrieval imho. It's probably an artifact of the underlying relational models (and the relational output it has to generate) but still.
It could have been wrong, but main argument was whether SQL was a good language for retrieval or not, and for me that's a no. It's probably subjective though :)
