How so?

LINQ has nothing to do with ORMs, it's a generic querying/transform syntax that can operate on any kind of data structure, and it's expressiveness allows it to be seamlessly translated into SQL by EF and others.

Also it's hard to beat the static-typed nature of C#/EF and the fact that entities are just plain classes with no special needs or inheritance. They can be as "active" as you need them while the DbContext wraps everything nicely.

ActiveRecord surpasses all other ORMs in memory usage and slow execution, that's for sure.

I like the ergonomics of it though.

I'm dealing with some rather fun EF code inside triple nested for loops that runs several thousand queries before throwing a validation error. Now, I know that's the devs fault and not EF, but EF made it all just seem like harmless object oriented programming and not set operations.

I almost feel like I'd like EF for write operations, and Dapper for read operations. Strike a balance.

If its memory usage and execution speed are deal-breaking bottlenecks for you, then you're working at a scale few people actually work at. Here in the line-of-business web app electron mines, I get to optimize for developer productivity and simplicity.

Agreed. I only touched Rails briefly but I loved ActiveRecord.

Ive seen so many awful queries with terrible performance out of EF.

LINQ is cool, and EF is alright if you have a decent team with good practices, but it takes a lot of discipline for it not to turn into a hot mess.

I suspect you haven't yet seen tge power of LINQ, it's not the chaining that is its point - it's the lazy evaluation. It's not at all limited to DB operations.

Every use of LINQ I've seen in .Net codebases has been to perform (more slowly) transformations or aggregations that should have done in the database.

Sounds like you've worked with poor code/developers. LINQ with EF translates into DB queries including aggreations and transformations. That's the whole point of compiling the query, unless someone either didn't understand the query they were writing or explicitly chose client-side evaluation.

Hello. LINQ isn't at all limited to LINQ-to-SQL. That is simply one of the numerous IQueryable providers, which is also possible to implement yourself by doing some expression parsing.

And for the record I hate LINQ to SQL.

First time I saw it was in Smalltalk-80 collections, .NET was yet to be invented:

    (#(1 2 3 4 5 6) select:[:e | x isPrime]) collect: [:e | 2 * e]