well, you got it in the first paragraph - because Windows isnt Unix, and people dont use it for production. F# is in theory nice, but devops'ing windows, I just dunno man.
I've heard there's also good F# support via Mono now (but then again, I dunno about devops'ing with Mono... I wish someone had the balls try this and post about the experience...)
I've been deploying F# into production for a couple years, on to both Windows and Linux. They're rather simple daemons that talk to databases, message queues and filesystems, and do telecom logic (routing/billing).
Overall, Mono has been incredibly smooth. I prefer to compile from source as RedHat doesn't come with packages for mono. That takes time, but isn't a big deal. F# support seems lacking when it comes to some of the tooling (compiling, interactive).
mono-service, the service daemon to act like a Windows Service host (allowing same code as on Windows, and ~5 lines to a minimal daemon) sometimes has acted weird, but it's been due to how it handles it's runfiles and lockfiles, and once you know that it's easy enough to make sure they're ok. (As in, if one user ran it, the perms are wrong so another user can't even check it, and the error messages aren't there/clear.)
F# performance is on par for .NET. If a certain high-level feature is not generating great code, there's always the option to drop down or approach another way. F#'s much more flexible than C# when it comes to performance.
F#'s why I stay on the MS stack. .NET is pretty compelling with it's base library and great tool/developer support. But after seeing powerful languages, I just get so annoyed with the verbosity of things like C#.
It got _better_, way better, much nicer than Java. It's not even remotely gone. Type inference is crap in C#, and they even admitted in some cases, it was due to compiler design problems, not language design[1].
Even local vars can't be type inferred if they're functions, because of C#'s confusing decision to use the same syntax for lambdas and quoted code.
The ASP.NET MVC team resorted to using reflection on anonymous types, because there was no lightweight way to pass in a set of options at runtime. With a more expressive syntax, that'd be needless.
C# has statements that aren't expressions, which really bulks up code and adds flow for no reason. In F#, even "if" and "try" blocks are expressions which again keeps slimming things down, and more importantly, keeps the code simpler.
In one direct "line-by-line" translation (C#->F#), F# reduced the number type annotations I needed by 95% (1/20th).
No pattern matching (and thus no active patterns!), little type inference, no syntax for tuples, no lightweight function syntax, no code nesting, no workflows, (and a weird hardcoded one just for async), no top-level functions, no custom operators, and C# is flat-out downright clunky when compared to F#.
It may be one of those "you don't know what you'll miss until it's gone" kind of deals. I've used C# now and then, even last month on an entire project, and it just feels tiring.
