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.

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/

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.

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...

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

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.

A part of me jokes that Micro$oft only invested in OpenAI because it's the only sensible way to browse .NET/Nuget package(s) documentation. The other part knows it's dreadfully true.

In all their docs they now have links directly to the source for the method you are looking at, for example https://learn.microsoft.com/en-us/dotnet/api/system.string.s...

As for source for nuget packages, it's easy to enable source link to make that happen too, it's just that this is all pretty new so not every package is doing it.

I agree with you, but I think this is most likely due to how relatively new open source C# is. I'd hazard that most C# being written is still done by enterprises/companies as closed source. I feel this will improve over time, as long as Microsoft continues down the road of being open, and doesn't pull back what they've been doing in the last few recent years.

Some of these features are provided by tools like Resharper, and I wonder if there isn't some kind of agreement (whether written or unspoken) where they don't step on each other's toes. To be honest, most documentation I have seen written in C# projects still makes me reach for the source code due to poor quality. Having lots of autocompleted tooling doesn't help when it comes to reading, only writing, in my experience.

Sandcastle Helper File Builder has been around forever and started as an internal MS project IIRC, but for some reason few libraries use it.

https://github.com/EWSoftware/SHFB

Here’s a way to write tests next to the code: https://clipperhouse.com/go-test-csharp/

(Whether I recommend it, not sure! I did it and then undid it, with suspicion that tests were taking longer due to, perhaps, worse caching of build artifacts.)

If you do have useful feedback, please submit an issue or contribute a PR to dotnet/runtime. That’s how many performance improvements in LINQ come to be, that the post discusses.

Your library looks very interesting, but I think you might be setting things up ahead of time to be dismissed. There are a large number of using statements, which is not a big deal for those who understand breaking up projects into appropriate pieces for exactly what you need, and keeping boundaries between different concerns. Most developers don't structure their projects the way that you do, and I say that as a positive towards your implementation, but often little things like this can hold back "the most common-denominator" when it comes to developers. I will admit right off the bat that you are far more well-versed in C# and .NET than I am, but I'm coming to this as someone that has worked with lots of junior developers that already struggle with standard LINQ syntax, methods, and (in particular) performance.

You do mention these things in your README, and I appreciate it, as most are set on "selling" their library instead of actually listing what it exceeds at and the purpose. Your comment on being non-idiomatic is another issue that I see (again, talking about people learning and getting used to C#/.NET). Only in my opinion, I feel like Microsoft want to keep their tools and languages following certain practices, and I get that your naming follows more functional programming practices to make them natural to FP. I feel like often, little issues like this are very large to Microsoft when it comes to looking into improvements.

I starred your repo, and am very interested in what you've put together here. On the last few major applications I've built (I normally build content management systems that are highly customized, that I tend to not call apps), I've used a Result<T> type that seems to be roughly the same as Option<T>. I wrote that sentence, and then went back to look at your library, and as much as I thought I knew about FP, I really don't. I think I'm really decent at C# and doing some complex things with it (I mainly use Umbraco CMS, and I've gotten my code to run websites under the minimal recommended requirements of the base Umbraco software). With that said, I read a lot about FP, but still have tons of issues picking it up. F# For Fun And Profit is the closest it's made sense to me. In the end, all this is to say that it's nothing that you're doing wrong. Microsoft is going to target the average or beginner developer, because that is the vast majority of developers that they have in their environment.

I hope that you library can gain some internal improvements, because it looks like you've spent an enormous amount of time on this, and you have enough stars on GitHub to at least indicate that people are actively using your library and getting benefit from it. I apologize if any of this came off as dismissive, I think what you've done here is exciting, and feel like you've set up enough documentation where I can slowly pick up concepts that I'm unfamiliar with.

I do find this an interesting thing often said in the .NET community. Yet the question "Why not just use F#" comes up in my head every time someone says this. C# has been playing catchup for many years.

If it is F# that is pushing a lot of innovation in the .NET ecosystem and many years in features ahead (at least it was a few years back) why not reward that effort through its use? We should encourage the behavior we want out of these language development teams after all by voting with our feet. Worked with the Java ecosystem for example - even Java now is improving. It would create a positive feedback loop (like most other innovative tech) where more market would create more engineering effort on it as well.

Reading these forum's over the years it feels like many C# people really want to stick in their camp and wait "just because" - it almost feels "tribal" and their team is "C#". I just don't see this culture in some other language ecosystems - makes me think if F# was in any other ecosystem than .NET it would of thrived a long time ago. That's just my impression though.

I'd kill for units of measure too. It makes maintaining any kind of engineering or scientific code so much easier.

You can largely already pretty easily incorporate DUs using OneOf[0] and Dunet[1].

A practical example of using this: https://chrlschn.dev/blog/2024/07/csharp-discriminated-union...

[0] https://github.com/mcintyre321/OneOf

[1] https://github.com/domn1995/dunet

It's an open secret and cited many times by officials (eg Hanselman) that F# is the testing playground for C# (and vb.net) features.

Do not, my friends, become addicted to LINQ. It will take hold of you, and you will resent its absence.

It’s still less powerful than something like polars

That is because all the hot-and-new in .NET web development is Blazor, and it is not really popular outside of Microsoft's Blogosphere (and IMHO never will be and go down the same way as Silverlight did). The "venerable" technologies are still present in .NET 9 and still work, get maintained etc.

Doing web dev in .NET nowadays for me is mostly creating HTTP/JSON/REST APIs and using whatever FE framework you like to interface it (for me that is React or NextJS). The keyword you want to search for is "ASP.NET WebApi" or - more modern - "ASP.NET minimal API".

You could still do .NET MVC server-side rendering using "Razor" (the markup language in ASP.NET MVC - search for "ASP.NET MVC Razor".

I've recently taken an interest in web development using C#. It seems to me that ASP.NET is THE way for creating web applications in .NET, for better or worse ("for worse" since lack of alternatives sounds a bit suspicious to me...).

Anyway, I came across a podcast featuring the author of "ASP.NET Core in Action", Andrew Lock, and he seems to know his stuff. I haven't read the book yet, but maybe this is the book you are looking for.

--

1: https://dotnetcore.show/season-6/navigating-the-aspnet-core-...

2: https://www.manning.com/books/asp-net-core-in-action-third-e...

A bit of the beaten path, but F# with Fable is a very powerful combination.

On the server you can run ASP.Net using Giraffe, which is a Functional Programming layer with comparable performance to C#.

On the front-end, you can write React in an true Functional Programming language.

And of course you can share F# code between frontend and backend.

I've learned by doing, but here you go.

Books: C# 12 and .NET 8 - Modern Cross-Platform Development Fundamentals - Eighth Edition: Start building websites and services with ASP.NET Core 8, Blazor, and EF Core 8 by Mark J Price

Web API Development with ASP.NET Core 8: Learn techniques, patterns, and tools for building high-performance, robust, and scalable web APIs by Xiaodi Yan

Turorials: series of tutorials on YouTube by IAmTimCorey and Shawn Wildermuth.

For server-rendered UI, look for resources that uses Razor, ignore Blazor stuff at the beginning.

For .NET Backend/JS Frontend, look for resources that uses minimal APIs. MVC is also good but has a lot of backwards compatibility baggage that led to the creation of minimal APIs.

Those attributes correspond to the benchmarking library used in the article. Unit testing & benchmarking code does typically look kind of like a plate of spaghetti.

That said, you would never get a PR through me that does this in the actual business logic. You can use things like AspNetCore without touching a single attribute if you really don't want to.

What .net code are you looking at? I rarely use attributes at all.

I can relate. I used .Net at the beginning of my career, and that one was one of the few nice things. I enjoyed building in C#, until one day I realized that MSFT is more like a mental prison (apologies for the strong negative word) - mind that it's my personal feeling at that time, many things have changed positively since then, although I moved on already.

Also, I too, use Clojure today - it is very nice.

It’s been consistently one of my favorite tools for a good decade. I don’t know how much Microsoft is paying them to keep it Windows-only because that’s the only reason I keep windows around, and I’m sure that goes for a number of important developers.

Maybe you've been unlucky but LINQ didn't really seem all that interesting to me using it.

It's pretty well put together but it was very hard to work out the patterns of what it was doing underneath e.g. I could not tell you now how to implement a custom IQueryable (I know where to look but couldn't tell you the rhythms of it) for some database and I am the type of person who usually does go and find that kind of thing out before using something for a "serious" project.

Maybe it's just a microcosm for C# as a whole - very productive language, good design team, quite hobbled by it's weird/philistine upbringings: Bjarne said within C++ there is a simple language trying to escape, in C# you basically have a simple language buried in nouns.

LINQ is largely based on FP stuff, also how Smalltalk collections work.

It is relatively easy to find similar capabilities in most languages nowadays, unless one is stuck on Go, C and similar.

I’ll get started then end up on a rant but..

This is really the thing with the entire .NET stack that’s very hard to communicate. The standard library and framework design are so well thought out relative to anything else out there. More than that, the support within VS is beyond any other dev tool that exists for any other language - it’s not even particularly close. Edit-and-continue comes to mind, which despite how many times people confuse the two is not hot reload, and is wildly more productive and useful.

I remember back close to 20 years ago DHH was espousing Ruby/Rails and that the concept of types at all were a code smell, and thinking “you’re just very wrong, and clearly aren’t familiar with what else is out there”. Eventually a lot of that crowd moved to Node, then to typescript, and came around.

VS Enterprise (expensive as it is) had features 15 years ago that still seem magical when I show them to JS/TS folks now. IntelliTrace is one that comes to mind - there’s nothing remotely close to it’s snapshot debugging that I’ve seen anywhere else, and I’ve really looked.

The big problems with the ecosystem are that the docs are exhaustive but terribly boring, and not well explained from a learning-something-for-the-first-time perspective. They also really expect that everything you do is the Microsoft way, so if you’re trying to interface your code with something like an Avalonia UI, you’re on your own.

The language is absolutely wonderful though, even when used with Rider. The productivity relative to node/typescript is better enough that it crushes my soul having to go back to wrestling tsconfig and imports after working with .NET references for even small changes. So many of the little things I used to take for granted really just work, and work well. It’s just a wonderful piece of work executed over decades, held back by poor community outreach and badly written documentation.

If you like LINQ, you should really give F# a try.

It's just an API for JIT, basically metaprogramming. It's cool but you can definitely do a similar thing in pretty much every high level language.

With scripting languages, it's all JIT :)

The C# teams progress on this has been slow. Keep in mind the CIL bytecode has had such capabilities for at least 20 years now and only in the past like decade are we seeing more features and optimizations around LINQ and System.Reflection.Emit.

Dynamics were extremely slow in C# and if you look at the CIL generated you see why. It's possible for example to use something like a Haxe anonymous types[1] to optimize Dynamics so that CallSite caching is way more performant.

I am pretty sure in C# the only way to accept an anonymous type is as a dynamic value, so even though the type of the structure is well-defined at compile-time, it will still rely heavily on runtime reflection/DLR with no additional caching beyond what DLR does for any other dynamic type.

Anyways, this leads to niche libraries being built for handling dynamic data like JSON performantly.

Which leads to annoying things like .NET libraries/apps being incompatible (without some adapter) if they use for example, different JSON libraries under the hood. (See [2]).

Problems like these (the lack of actually good JIT/dynamic code support) in my opinion significantly slow down the .NET ecosystems development, that's why it always feels like .NET is just catching up with features other popular languages have.

To be fair though, much of C#'s lag is owed to Microsoft's contribution to .NET being mostly technical debt. Almost everything good that came out of .NET came from open source/non MS teams (like Mono).

[1] - https://haxe.org/manual/types-anonymous-structure.html

[2] - https://learn.microsoft.com/en-us/dotnet/standard/serializat...

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.

While LINQ does include a library of extension methods for functional programming with .NET collections (which is great), it also includes "Expression Classes". In a nutshell, this allows a user to pass a single expression lambda to a function, and the function implementor receives the abstract syntax tree for the lambda, not the lambda itself. You can then not only receive and analyze these trees, you can also manually build and compile them. This effectively allows a limited set of runtime macros within .NET.

> Basically allowing for a uniform way to query data which is reminiscent of a more modern version of SQL.

Pretty much. There's the "language integrated" version which looks a lot like SQL:

    var foo = new List<int> { 1, 2, 3, };
    var response = from x in foo where x > 1 select x.ToString();

But that just translates to the method-orientated one which many people prefer

    response = foo.Where(x => x > 1).Select(x => x.ToString());

If instead of querying a List or Dictionary you query a database, using an ORM (usually Entity Framework), that will actually get converted to SQL and run on the DB.

> Basically allowing for a uniform way to query data which is reminiscent of a more modern version of SQL (in my optics anyway)

It's more general and reusable than SQL, so you can map a subset of it to SQL, which is what some object-relational mappers do.

Most of the time, it is not because there were too many slow things to be improved, it is mostly because they are adding more facilities to the runtime, enabling other performance improvements.

For example, the ReadOnlySpan type is a recent addition to the runtime and it will allow faster iterations when used. They simply enabled Linq to use it now.