I agree that F# is a great language, but there are a couple projects in which I favor C#.

One reason to favor C# is that it just has better IDE support, hands down. In addition, if I'm working with C# devs it's just nicer to use something everyone already knows.

As far as the language goes, though, perf sensitive stuff often makes more sense for me to do in C#. This is a combination of reasons:

1) I generally have a better sense of the IL that a given C# program will generate. This is both because I am a C# compiler dev and because C# is closer in form to the .NET IL than F#.

2) I have a better sense of the actual machine code that will be generated for C# code by the JIT. This is almost entirely because I am a dev on the C# compiler.

3) The language/framework teams are very data driven. The population of F# developers and F# code in comparison with C# developers and C# code is like a drop in the bucket. There are hundreds if not thousands of C# developers for every F# dev. It is almost a statistical certainty that C# JIT hot spots will get optimized before F#.

4) The fastest F# is usually very imperative and is essentially the same as the C# code.

I've found that with F#'s inlining, you can get significantly better code generated. The C# team has seemed hostile to the concept of implementing many compiler optimizations, and the JIT still does a poor job inlining. (And still no SIMD...)

Even in C#, imperative style will be faster. Without better type systems and much better compilers, that won't change (but F# could implement fusion a la Haskell). It may be "essentially the same", code, but with 1/20th the type annotations. It adds up.

I've not found a case where there'd be an excellent C# programmer not capable of using F#. Sure, if it's a little project and it's required that "random" C# programmers be capable of working on the codebase, fine, OK. Otherwise, the benefits of the language outpace the minor learning curve.

RyuJIT and ProjectN are supposed to tackle the quality of native code generation.

I wish F# had first class support from ReSharper.

F# tooling has been improving like crazy over the last ~6 months; most of that work has been focused on refactoring tools, compiler-as-a-service (aka "Foslyn"), and compiler-development tools, so it's not totally out of the question that someone could implement an F# language service for ReSharper in the semi-near future.

What gets me is that CodeRush has had first class support for F# for years now, and JetBrains still hasn't given it any love in ReSharper. Perhaps it's already underway and JetBrains is just waiting to reveal.

> But F# is so much better that I can't think of a single reason for choosing C# over it.

Your co-workers won't learn it unless boss says so.

I would say moderately better. E.g. "C# is so much better than assembly language".