Re:Introducing Bing Code Search for C#
by MichaelGG on Tuesday February 18, 2014 @12:43AM
(#7256597)
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.
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.