| I have a fair amount of experience in both F# and Ocaml and don't think the lack of modules harms F#. The trick I had to learn was to think of F# as its own language and not try to write it as Ocaml or Haskell. What I do sometimes miss in F# are existential types. I also wouldn't say objects in F# are less natural. This is only opinion but, I prefer F#'s lighter object syntax and its object expressions are great. Active patterns also provide an expressive option for dispatching on abstract datatypes. The conflicts vs .NET I've found with F# OOP are when implementing comparison operators, or when interacting with frameworks that want public fields. Other than that, there's not much friction. I suppose there is friction when it comes to MS tooling for producing Windows UIs but then, F# also has Fable and Elm inspired UI kits for various platforms. Going AOT route will also meet with some friction. Comparing languages comes down to what problem solving approaches they make difficult by default. In that light, F# is much more properly a "functional" language than C#. The language is designed from the ground up for recursive algebraic data structures, HM type inference, flexible pattern destructuring, null avoidance, exhaustive matching, computation expressions, idioms around composable higher order functions, clean syntax for function types, immutability and sound type guided development. It also has a light python like syntax and like all MLs but perhaps even more so, is pragmatic when it comes to the use of esoteric design concepts. The philosophy is not to be functional and pure for their own sake but about composing language defaults which force certain types of correctness promoting approaches. F# also has units of measure and type providers. They're probably less often used. But just the json, html and xml providers are useful on their own. To be clear, this isn't arguing F# vs C#. Such arguments are extremely boring. It's emphasizing what core design decisions distinguish the two languages. |