A simple 5 second google search would answer your questions.
To be honest as to why the answer is often anyone who wants to use an OCaml like syntax but have access the debugging tools of visual studio or mono and access to the libraries written for .Net.
We use it to write our proprietary trading system.
http://fsharp.org/testimonials/#tabbles-1 Completely in F# see comments above
http://www.rawbots.net/ are using F# in a very significant way and are in the process of making it their primary language.
http://fsharp.org/testimonials/#path-of-go whole AI logic in F#
http://fsharp.org/testimonials/#yan-cui backend in F#
http://www.galaxywarsthegame.com/ uses F# entirely
http://www.assettocorsa.net/ uses F# to prototype their vehicle dynamics.
and many more here http://fsharp.org/testimonials/
F# has nearly a superset of C#'s functionality, but with a far better fundamental design. It requires much less code, and results in far fewer bugs. And the biggest tradeoff is that Visual Studio's IntelliSense is a bit less capable with F# than C#. Performance wise, F# usually matches C#, but has more flexibility to outperform it in some cases.
The F# team has a strong background: They were the ones responsible for bringing proper generics to C# and the CLR. Without them, the CLR would probably have a lame generics system, such as Java. F# also demonstrated how to properly do async on .NET half a decade ago, which C# 5 finally picked up.
So if you're on .NET, there's little reason to not use F#, unless you're in a shop that needs replaceable warm-body programmers.
If you're not on .NET, there are perhaps better languages (Haskell), but that comes at a cost of having less tooling and libraries.
examples: math, science, economic fields.
* Easy multi-platform targetting and platform bindings without fuss.
* Mature and supported BCL and 3rd party libraries
* Access to the .NET ecosystem tooling like profilers, debuggers etc
* Easy to use Native FFI without having to write boilerplate C stubs
* more predictable reasoning about performance because of strictness by default.
* Built-in Units of measure without perf cost.
* Type Providers allowing typed access to untyped data and much more
[F# 3.0: Data, Services, Web, Cloud... at Your Fingertips] (http://channel9.msdn.com/Events/TechEd/Europe/2012/DEV338)
* Built-in support for runtime code quoations, with code inspection
* Built-in support for runtime reflection
* Subtyping without greenspunning around.
* Easier to fallback to imperative code.
* Extensible computation expression syntax for more than just monads.
* .NET runs everywhere now without problems, the JVM doesn't have a reliable IOS implementation and Dalvik on Android is too slow for the things I'm doing and many desktops don't come with a JVM installed.
* Better type inference
* FP isolated from OOP
* Lighter indent aware syntax.
* Easier to reason about performance because of lower abstractions
* Pattern matching can be used in performance sensitive situations.
* Easier equational reasononing because FP and OO are isolated from each other.
* Initialization order bugs can't happen easily by design due to the way class ctors work.
* A generics aware runtime so cross language .NET interop is seamless and without perf cost.
* Built-in Units of measure without perf cost or having to wait for a mature macro'ed implementation..
* Built-in Type Providers allowing typed access to untyped data and much more without having to wait for a mature macro'ed implementation.
Mono provides full support for F#. The F# compiler is open source (Apache license). MonoDevelop has some support for F#, but I haven't used it.
I don't fundamentally see the difference in deploying a runtime like the JVM over Mono. Mono even lets you pre-compile to native code (that's how the run on iOS, for instance), so you don't need to install the Mono runtime.
I use F# in production on Linux machines (telephony applications) and have so for many years. We use Windows to develop, test, build, etc. and then copy things over to Linux and it just works.
It's not a fundamental difference, it's about being confident the tools and support you need will be available. With the JVM you've got the full weight of IBM and Oracle behind you, and thousands of vendors selling things like latency-optimized JVMs, heap analyzers, managed hosting services. Likewise with the CLR you've got MS and a whole ecosystem of companies building tools around their VM. With Mono I don't get the same level of confidence that I'm moving with the herd, that there are many other businesses who will have hit any possible problems, that I can hire people who've used the platform before...
But my tooling comment was mostly about the development tools. I'd be super-nervous about developing on one OS/VM and deploying to another; don't you find you hit VM bugs that weren't present when you tested?
* Active Patterns
* Built-in support for Unboxed Structs with Layout control and operator overloading
* Unboxed floats, not just for 64 bit ones syntactically present in arrays
* Built-in control over inlining
* 32 bit ints not 31
* Built-in support for runtime code quotions, with code inspection
* OOP abstractions without perf loss
* Built-in support for Operator overloading
* Polymorphic print function
* Mature Multicore friendly runtimes
* mutable local variables on the stack
* Cleaned up offside-rule indent based syntax with optional OCaml style override.
* Partial application of Discriminated Unions like List.map Some [1; 2; 3]
In OCaml you have todo List.map (fun x -> Some x) [1; 2; 3]
* Methods on Records and Discriminated Unions
* Extension Methods
* Built-in syntax for Array slicing
* Built-in syntax for sequence based for loops
* Built-in syntax for List / Array range construction like [1 .. 10]