F# is hardly modern functional programming. It's more like a better python with types. And that's much more ergonomic than C#.
Haha, no. Microsoft barely talks about F# at all, and has largely left the evolution of the language up to the open source community that supports it. Furthermore, you shouldn't take your cues about what a language is best suited for from marketing types, you should evaluate it based on its strengths as a language and broader ecosystem. If you seriously doubt that C# is a better comparison to F# than Python, then I suspect you haven't used either C# or F# and you're basing your views on marketing fluff.
It’s pretty easy to stick to pure F# if what you want is the pure functional programming experience. But what I like about it is its pragmatism, and this is a big reason why it’s the language I chose for the course. It is by-value, eagerly evaluated by default, and has an easy-to-learn idiomatic syntax. It has a large and well-behaved standard library, and you can use C#’s excellent standard library if you need additional things (e.g., mutable data structures). I have used F# in many performance-sensitive applications, and the fact that I can say “you know, inside this function, I’m going to use mutability, raw pointers, and iteration” has been a lifesaver in some places. But because it is a functional language, I can also abstract all that away and pretend that it is functional.
I understand why other FP folks dislike this approach. But the insistence on purity makes many problems artificially difficult. Debugging a lazily evaluated program is a nightmare. There are lots of times I want a well-behaved language but I am not willing to do CS research just to solve common algorithmic problems. The generally pragmatic streak from the SML family makes them easy to love.