F# is an amazing language. It's "impure" in that it is neither Smalltalk ("pure OO") nor Haskell ("pure Functional") but its creators have struck an excellent balance between these two paradigms using OCaml as a basis -- but not the specification -- for the language. There are features in F# that OCaml developers wish they had! When you finally wrap your head around pattern matching, active patterns, quotations and computation expressions, you will not be able to look at mere mortal languages like C# and VB.NET with the same enthusiasm. The F# compiler is one of the smartest in existence and its type inference, tail-call optimization and code generation capabilities are second to none on any platform. F# and Scala are doing the same thing on their respective platforms -- bringing the worlds of OO and functional programming into practical symbiosis. F# kicks Scala's butt really only because the CLR kicks the JVM's butt in two specific areas: The ability to support tail-call optimization (which is critical to making functional programming's reliance on recursion efficient) and the fact the CLR did not have to resort to "type erasure" to support generics ... so, you don't lose any reflective capability over types at all with its seemingly loosey-goosey type syntax. For myself I use F# for nearly all business logic and in the MVVM paradigm for the VM part, almost exclusively. Manipulating collections is a delight in F# and VM is about binding data and actions to the UI. This is a non-visual exercise and F# really makes it nice. Using it for GUI programming is an exercise in self abuse because the tooling support just isn't there, but that's OK, what it does do is so outrageously cool and useful in real programming that it doesn't need to do everything. F# justifies the CLR's support for multiple languages in ways C#, VB.NET and other semantically similar languages cannot.