The function chaining is a game-changer, if you're talking about maintainability...
The temporary variables are eliminated,and the type-based chaining self-verifies for new modifications, neither of which you get in C#. Also, thanks to better support for higher-order programming, common post-launch activities like performance upgrades and async tweaking happens with stronger guarantees and oodles less code.
In terms of essence: namespace shielding and modular composition gives numerous opportunities for logical encapsulation and complexity management that are not feasible thanks to C#s extension semantics and extension method requirements. All of the above can be defined in one type, for example, instead of multiple... The end product is just wildly more cohesive in F#/OCaml, with more options throughout to produce more maintainable solutions.
F# can also use (a slightly improved), version of C#s extension semantics, as needed. But the functional composition, currying, Discriminated Unions, and exhaustive pattern matching in conjunction with the module syntax yield a final product that is markedly smaller and distinctly more maintainable than it's C# counterpart.
Not to mention: from a syntax and readability perspective this just destroys its Fluent Interface counterpart, in about a third as many LoC. Start looking into things like custom operator support, DSL support, computation expression support, etc, and the maintenance improving possibilities just blow the .NET baseline out of the water.
I completely agree that F# is superior to C#, I use it when I can, but the gain from "fluent extensions methods" in C# is significant, and improves the code quite a bit. The main benefit over F#, is the pool of developers that understand C# is significantly bigger. This is a parameter I need to take in to consideration because of the developers I hire, there is few and far between the one that grok F# and FP in general.
Fluent extension methods are better than no extensions at all, I agree :)
I tend to look for general competence in new devs, because that persists across platforms and pivots. In general it's odd that we expect devs to know every language, tech, and cloud platform under the sun but draw the line at basic mathematical concepts mapped into programming decades ago... Using both sum and product types is fundamental to proper modelling, IMO.
I also think comparison between C# and F# based on "tricky" FP concepts is really odd in modern times...
On the one hand: if a new hire can't grok FP in F#, how can I trust them to do serious work in C#? OOP & FP synergize wonderfully, and the language has been openly trending towards FP ideals for a decade now. Those FP concepts are now modern idiomatic C# and also very important in tricky domains...
On the other hand, if I'm doing work that makes me think correctness is even a little important why would I want to do it in a language almost-as-good that provides no guarantees and requires more complexity? Why bring a footgun to the party if I'm already worried about quality and some rando new hire? Seems like people who don't grok the basics would do better in a stricter environment with less room for f-ups.
For my money I'll readily take a mild bump in on-boarding costs for productivity, production, and correctness guarantees forever. Not to mention the improved caliber of candidate one gets from finding self-selected A-grade techies and advertising an aggressive dev environment.
In the current situation, getting a competent dev that seems to be able to grasp FP naturally, does not require a mild bump in on-boarding cost, but a significantly higher salary.
Right now I'm hiring developers right out of school and put them through a mentor program, hoping that they turn out good.
