[ThinkBeat]

C# in its current state has IMHO acquired many features from F#. You can get close to writing purely functional code in C# now.

I think with all the changes and extensions over time to add ever more features to C# so you can write whatever paradigm you want in it is a bad idea.

I would much have preferred to keep C# OO and use F# when you want to go functional.

Or just create G# which is the everything mashed together language that C# is close to being.

[pjc50]

> You can get close to writing purely functional code in C# now.

It seems that FP advocates overlook just how great LINQ is, even if it exists within the impure swamp of regular C#.

[ReleaseCandidat]

I don't really know Linq (and haven't used F# for 2 years, using .Net 5), but isn't F#'s `query` the interface to Linq?

https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... https://fsharp.github.io/fsharp-core-docs/reference/fsharp-l...

[WorldMaker]

Yeah, that's the F# support for it. The interesting bit is that C# supports much nearly the same query syntax (`for item in something where item.IsInteresting select new { name = item.Name }`) and secretly supports just about any arbitrary Monad you want to write [1]. Just as C# also was one of the first languages to take something like F#'s async { } builder for async/await syntax, as a different Monad transformer (that C# also built to be duck-typable for any Monad that fits the right pattern).

LINQ and async/await alone can be heady "gateway drugs" in C# to learning functional programming fundamentals (including the deep, advanced fundamentals like Monads), and C# only seems to continue to pick up little bits of FP here and there over time.

There are definitely lots of reasons why even some of the biggest FP fans often think "C# is good enough" without needing to reach for F# in 2023. (Which is why the post here, and the comments above in this same thread lament that F#'s biggest problem is the shadow that C# casts.)

[1] Mark Seemann did an entire series of blog post on coding common Monads in both F# and C# and the C# code is very interesting at times: https://blog.ploeh.dk/archive/

[progmetaldev]

I don't dispute your claims, as they are subjective. I do know that I enjoy a lot of the functional aspects to C#, but I think it's something where you need to have a real discussion with your team and decide a coding style and feature implementation for your code. If your team can't all speak the same dialect, you're going to have issues. Having seniors able to work with juniors and discuss the functional aspects, as well as when to use things link LINQ, goes a long way towards a consistent and easily understood codebase. I know not every shop has this luxury, which is why I still agree with your statement.

[ThinkBeat]

You bring up good points.

I often think about C.

I learned C a long time ago, I still have the KR book, and if I look at C code I can get a good idea of what is happening, even though I haven't kept up with all the changes.

In C# now, two developers can write code that accomplishes the same but might not be able to read each other's code. I dont think that is healthy.

It is somewhat the Microsoft Office / Word approach to programming languages. Just Keep adding features on top of features.

[magicalhippo]

> I would much have preferred to keep C# OO and use F# when you want to go functional.

What's stopping you? You can mix and match C# and F# on the .Net platform, no?

[jackmott42]

Yes, its pretty straightforward to have a .NET solution with a mix of C# and F# projects that can refer to each other.