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.<p>The post I submitted refers mostly to optimizations to those extension methods.<p>This clicked for me after having learned Haskell. It also shares some of Haskell's features/pitfalls, such as laziness.<p>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.
I don't understand why the dotnet team doesn't invest more resources and time into tools: doctests and documentation generation, better and faster unit tests that I can write next to the actual code, easy access to the source code, no need to decompile a Dll to see it after pressing F12, a central place for packages and documentation like in pkg.go.dev or docs.rs . Most packages in nuget have no documentation at all, or only in readme format on GitHub, or a short Wiki on this page. Other environments like Rust, Golang, Java, Python are light years ahead when it comes to these aspects.
"LINQ Performance improvements" really should read: "our own List<T> implementation performance improvements". Microsoft seem to spend their time improving what they need, rather than spending time on general improvements. LINQ (the syntax, not the method extensions) needs investment. Primarily around lambda allocation and potentially on compile-time reduction of lambdas.<p>It's time to have value-type local lambdas, or a strategy that doesn't make lambda allocation the overhead that it is. And also there really should be wildcard support (`_`) for LINQ variables by now. Which was been completely ignored when they were brought in for lambdas. It should also be possible to use a lifted-type (like IEnumerable<T>, Option<T>, etc.) as the final item in a LINQ expression, rather than `select ...`. The select adds overhead that isn't needed for certain use-cases and limits things like tail-recursive LINQ expressions.<p>Libraries like mine that go all-in on LINQ [1], but aren't using `IEnumerable` or `IQueryable`, or any of the LINQ extensions, continually get ignored because MS are focusing purely on improving the performance of their own projects.<p>A good example is the improved lambda inference. It was only brought forward because ASP.NET Core needed it for its minimal API. It seems like many of the features of the language/framework are driven by their own needs rather than those of the community. The absolute worst thing is the ever expanding set of 'magic methods' (like the LINQ extensions Select, SelectMany, and Where, but also GetAwaiter, and the rest). MS are adding capabilities for themselves (the compiler mostly) rather than do what is really needed and add proper higher-kinded traits to resolve the magic. So everything is weakly typed and only vaguely discoverable by the compiler :/<p>LINQ is one of those key differentiators between languages, yet it's been wallowing, pretty much untouched since C# 3. I think it's a crying shame that it has basically been ignored since then and, even now, they think LINQ is only useful for iterating lists. And primarily only their own list implementations.<p>/rant<p>Don't get me wrong, I appreciate all performance improvements, I'm sure it will help plenty of users. But the focus always seems to be narrowly targeted, which limits the potential.<p>[1] <a href="https://github.com/louthy/language-ext/">https://github.com/louthy/language-ext/</a>
Whenever I work in other languages/ecosystems LINQ is the one thing that I really miss. It's just such a nice capability to have available in the standard library. Beautifully designed given the constraints it had to work within.
Relevant section in the annual book-sized post on all performance improvements in .NET 9:<p><a href="https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/#linq" rel="nofollow">https://devblogs.microsoft.com/dotnet/performance-improvemen...</a><p>(for some reason HN would not allow to resubmit it, and the post was left by wayside not reaching frontpage)
Anyone knows of a comprehensive book/tutorial to learn end to end web development in dotnet. Most I have found are elementary, outdated or poor quality.
> Some more optimizations can happen when the chain ends up with methods like Count(), First(), Last(), ElementAt() or Sum(). For instance, OrderBy(criteria).First() can be optimized to execute as Min(criteria).<p>As useful as that might be, we should really be writing better code. This is interesting for dynamically generated chains, I suppose. But if these operations are done on bespoke code, this is kind of perverse positive reinforcement. The library itself is recognizing a sub-optimal pattern and correcting for it. I hope there's feedback, at least, that suggests improvements to the underlying code.
LINQ is so fucking useful and well designed feature of .NET ecosystem that it is unreal when you gotta use lang which doesnt have such a thing.<p>C# design team is/was unparalleled
OK, so since I've never actually bothered to look at what LINQ actually is.. there may be others in the same boat: "LINQ allows you to query any enumerable collections such as List<T>, Array, or Dictionary<TKey,TValue>.". Got to admit I still find the LINQ to DB passtru rather opaque even after reading up on it: <a href="https://stackoverflow.com/questions/30716776/passing-a-query-directly-through-linq-to-the-db/30716910#30716910" rel="nofollow">https://stackoverflow.com/questions/30716776/passing-a-query...</a><p>Basically allowing for a uniform way to query data which is reminiscent of a more modern version of SQL (in my optics anyway). Does anything library wise come close to this within the Golang ecosystem?
It's a shame, actually, that .NET performance improvements of up to x1000 could still be found after two decades and hundreds of millions spent on development.