Net 9.0 LINQ Performance Improvements

LINQ is a veritable footgun in any large team I find. While it's extremely powerful and really nice, it's so so so easy to blow your toes off if you don't know what you are doing. Some of my favourite screw ups I saw:

* Not understanding when something is evaluated.

* Not understanding the computational complexity of multiple chained operations/aggregates.

* Not understanding the expectation that Single() requires exactly one of something.

* Not understanding how damn hard it is to test LINQ stuff.

>Not understanding the expectation that Single() requires exactly one of something.

Sorry, but idk how it is footgun of LINQ. It is like complaining about 0 or 1 based indexing

>Not understanding how damn hard it is to test LINQ stuff.

Any examples? Because I struggle to see such

How much of that is LINQ-specific and how much is just the cost of using an ORM to build queries rather than typing them out as SQL?

I've never encountered testing problems with LINQ-to-objects.

I sort of agree. I recently had to code splunk a bug with 3 other engineers and we all got to a relatively complex LINQ and of the 4 of us, we all had 4 different interpretations when visually inspecting.

> Not understanding how damn hard it is to test LINQ stuff.

I disagree with this. Just run the LINQ query on a compatible iterable.

Regarding the testing, it's more the sheer multiplicative number of cases you have to consider on a LINQ expression.

> * Not understanding when something is evaluated.

Linq is lazy. .ToList() reifies. there, that's the gist of what you need to know. Not hard.

> Not understanding the expectation that Single() requires exactly one of something.

eh? There are a bunch of these methods, Single, SingleOrDefault, First, FirstOrDefault, Last, LastOrDefault and you can look up and grasp how they differ. It's fairly simple. I don't know what the problem is, outside of learning it.

> Not understanding how damn hard it is to test LINQ stuff.

Hard disagree. LInq chains can be unit tested, unless your Db access is mixed in, which is not a LINQ issue at all, it is a database query testing issue. LINQ code, in itself, is easily unit testable.

Single gives you some guarantees about the returned value. Use First/FirstOrDefault if you don't need those guarantees. You can also provide predicate for FirstOrDefault to select First element that matches your predicate.

> Enumerable.Single Method - Returns a single, specific element of a sequence.

Some overload descriptions:

- Returns the only element of a sequence that satisfies a specified condition, and throws an exception if more than one such element exists.

- Returns the only element of a sequence, and throws an exception if there is not exactly one element in the sequence.

https://learn.microsoft.com/en-us/dotnet/api/system.linq.enu...

> Enumerable.FirstOrDefault Method - Returns the first element of a sequence, or a default value if no element is found.

https://learn.microsoft.com/en-us/dotnet/api/system.linq.enu...

> I recently had to code splunk a bug with 3 other engineers and we all got to a relatively complex LINQ and of the 4 of us, we all had 4 different interpretations when visually inspecting.

You can write hard to read code with any framework. Yes it takes effort sometimes to make linq code clear, but you should not give up on it.