4 ms·

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

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.

MichaelGG 13y ago
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.
- pjmlp 13y ago
  RyuJIT and ProjectN are supposed to tackle the quality of native code generation.

MichaelGG 13y ago

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.

pjmlp 13y ago
RyuJIT and ProjectN are supposed to tackle the quality of native code generation.