[LittleCloud]

Speaking as a C# developer, who had in the past wanted to learn F#, but never got very far. What discourages me every time:

- C#'s good enough. Nothing's stopping you from writing functionally-oriented code in C# (and I do prefer that over traditional "enterprisey" object-orientation.)

- It's relatively difficult to have a codebase that is partly in C# and F# for incrementally trying things out. (I understand this is not really F#'s fault, owing to the .NET compilation model where C# and F# compilers each produce their own assemblies. And that Microsoft hardly cares about F#, and the tooling leaves a lot to be desired - admittedly I'm spoiled by C# tooling. )

- F# having its own implementations of concepts like async, option types introduces friction with C# obviously. I get that F# async is more powerful in some ways, but then again... F#'s option type is a reference type unlike C#'s Nullable<> value type, it's hard to see what's the advantage in that other than worse performance. One almost gets the impression that F# designers don't care about performance (while C# designers do in the past few years with additions to the ecosystem like Span<T>). This makes it hard to justify coding in F# for infrastructure libraries (which is what I often do).

[CSMR]

Lack of expressions is the main C# deficiency that will never get resolved. The other big advantage of F# is that it can be very easy to understand: file ordering means that you can read through from start to end to understand the code.

Ordinarily in a mixed codebase, the F# comes nearer the start, with C# depending on F#. That's because C# has lots of glue code to connect to the outside world (xaml, cshtml, EF...) and this is less straightforward to migrate to F#. The only problems with mixing languages is when you want F# in the middle of some project where it depends on some parts of the project and other parts of the project depend on it. But if you can identify something independent in a C# project and extract that out, you have already made the project simpler.

You can ignore async and use task. You can use async in the (very rare) cases when you don't want a hot task. You can also ignore Option and use ValueOption all the time. The struct types are new and have meant that F# does not have a performance deficit.

ValueOption is just better than Nullable<> since Nullable<> restricts to value types only. Resulting in Nullable composing terribly and requiring ad-hoc code everywhere.