Net 9.0 LINQ Performance Improvements

For me, the most useful part of LINQ is neither the IQueryable syntax tree based extension mechanism, nor the language integrated part (which I dislike), but simply the IEnumerable extensions. Originally known somewhat confusingly as linq to objects. Those allow me to write c# in functional style, keeping the code concise.

The post I submitted refers mostly to optimizations to those extension methods.

This clicked for me after having learned Haskell. It also shares some of Haskell's features/pitfalls, such as laziness.

There are pitfalls, sure, and honestly I wouldn't advise a team having no one somewhat experienced with basic functional idioms (including laziness) to use it. It can lead to obtuse and slow code if used indiscriminately. I try to lead by example myself.

C# has quite a few easy to use things that take a while to understand. In some ways it is a bit of an "experts only" language.

This is how I use LINQ as well. With some non-standard names, it has everything you need! Eric Lippert wrote a great series on monads tying it to LINQ:

https://ericlippert.com/2013/04/02/monads-part-twelve/

This is my preference as well, I love the functional aspects of the LINQ extensions for IEnumerable (and IQueryable)... Just easier to reason with IMO. Not always the most performant option(s) in for example (Entity Framework), but usually a pretty good option most of the time. I also like to use Dapper over EF.

Of course, C# projects tend to have a level of abstractions that are simply absurd to work with. "Enterprise" development makes my cringe more often than not.

Totally. I couldn't care less if the LINQ syntax had gone tomorrow, but functional composition is so powerful, and easier to maintain too.

If you like haskell, you might* like some of the other applications of linq's query syntax, like combinatoric parser construction. [1] The query syntax isn't hard-coded to do stuff with IEnumerable, that's just what it does by default. It can be used for pretty much anything. It works a bit like operator overloading.

[1]: https://github.com/acple/ParsecSharp/blob/da8d0cb9ec39e28dd9...

I would miss it for `let`, and for multiple `from` clauses. These are things that can be done with extension methods and callbacks, just not as elegantly.

`let` is just a .Select(), isn't it?

It’s hard to forget what you know and see through eyes of a beginner, but I definitely find C# to be a very “rich” language, in the sense of finding new features and ways of doing things the more I use it and as the incessant releases roll out. I like to think it’s still pretty easy to start with though if one is focused on the fundamentals. Lots of head room for progressively expert use, I guess.

A `Select` to a tuple or anonymous class which you have to carry around all the way.

If you look at how a LINQ query gets translated to a method chain (e.g. via SharpLab or let Rider/ReSharper rewrite them) you'll notice that multiple `from`s or `let`s can become quite ugly.

I've only ever used the method syntax for LINQ. I'm not a fan of having another "embedded" language inside my host language, especially since what is returned eventually needs to go back to C#. When I'm not using an ORM like Entity Framework or Dapper, I still prefer to place my data access logic with SQL into a separate abstracted project so it doesn't spill across my application (and can be replaced if I were to require a different RDBMS, although this has only happened to me once in 20 years).

For more junior devs using LINQ, setting them up with a profiler and the debugger I believe helps makes more sense about what is going on behind the scenes. Sometimes it's helpful to have them code using for-loops and standard C# logic, and then compare to how you'd implement in LINQ, to see the positive and negative of both approaches.

To add on to what you wrote, it amazes me the number of developers that don't understand you can use .Select() to construct named object instances. I'm probably using bad terminology, but something like:

    .Select(x => new Employee { Name = x.Name, DepartmentName = x.Department.Name }).ToList();

How do these developers use .Select() then?

Oh that's convenient, that's for sure.

There are some queries that are actually easier to compose in LINQ syntax than even in SQL. However, like everyone else, I rarely find myself actually using it. Anything really complex is done in pure SQL and everything else is method syntax.

But it is slightly more expressively powerful than SQL and way easier to follow, if you need it, than the method syntax.

Into anonymous types mostly, where you can't pass the type to another method. Example:

    .Select(x => new { Name = x.Name, DepartmentName = x.Department.Name }).ToList();

Same code as I wrote, except capture in an anonymous type. The documentation practically encourages this.

Why on earth they named map as s Select and flatmap as SelectMany, I'll never understand. Still vert useful tho.

(I first learned FP with Scala, so the names from there feel the most natural to me, tbh)

Edit: it just occurred to me it has to be SQL inspired or something like that.

Yeah it was intended to be easy to learn to people familiar with SQL. LINQ2SQL and Entity Framework are basically a way to query your database by constructing an abstract representation of your query using strongly typed bindings in your application code. So then the extension method syntax of it was a great way to sneak functional list programming idioms into it. Watching the proliferation of functional style in the .NET ecosystem over the past 15 years has been pretty impressive, IMO.

Indeed, I worked in Scala for a while, dabbled with rust on my free time and am now back to writing C#. Although I prefer the two first, I have to say the ergonomics have improved significantly in C# and there are now nice options for rewriting legacy spaghetti OOP-code.

Map is Select and filter is Where to align with SQL keywords.