Robert's blog
Robert Važan

C# still better than F#

F# is far from being a replacement for C#. It looks nice in simple examples, but building big applications with it is going to be a nightmare.

I've got an ideal application for F#: grouping and statistical analysis of logs from a desktop app. It's kind of like application analytics but much deeper. F# is perfect for this kind of job. Or is it?

F# has got some strengths that make it particularly attractive. F#'s pattern matching for example would be put to good use in log analysis. Primary constructors and structural equality can save tons of typing in data-heavy applications.

Unfortunately, as I started architecting the tool, I became aware of certain features of F# that made the job much harder that it should be. I started to see cases where C# has clear edge over F#.

I strongly agree with author of IronJS that the requirement to define mutually recursive objects together in one place leads to thoroughly messy code. Put differently, I like the ability of C# to define arbitrarily complex cyclic data structures with clean code. This drawback of F# is on its own enough to kill serious interest in the language.

F# proclaimed strength is its brevity. It's indeed true that many lengthy C# data structures can be reduced to a single line of F# code. The problem here is that F# has its own sources of verboseness, e.g. [<DefaultValue>], explicit mutable modifiers, and not-so-concise property definitions. When averaged over the whole codebase, F# doesn't really reduce code size over C#.

Another false advantage is the structural equality, which can be equally easily done in C# with reflection, serialization, or code generation. No point complicating language with such functionality.

I like that C# has only one class type. F#'s records tend to grow in complexity until they have to be converted to classes. C# also provides much better fit for .NET, larger community (and thus better tools & libraries), and allows me to organize code and files sensibly rather than in a way that pleases the compiler.

I think it all boils down to dogmatism. F# tries very hard to force you to do functional programming, which is bound to result in the same frustration as java's checked exceptions and a corresponding avalanche of workarounds.


I agree that C# is much better language in syntax and in debugging. Also curly braces helps organize your code and makes the next person understand and learn much faster which boils down to time and money savings. So F# and like are just hype just like the Ruby on Rails is a big hype and offers noting more than what C/C++, Java, C#, PHP offer.
It might very well be the case that F# is not a good fit for what you are doing for one reason or another - I have definitely seen cases where F# does not work as well as it could (although it never happened to me when working with data).

That said, if you want to make your point, it would be fair to share your F# code and let the people in the F# community look at it and perhaps help you improve it. If you are coming from C# background (just like I did a couple years ago), it takes some time to un-learn the C# style of doing things (which does not fit that well with F#). So, I think it is likely that there is a nice way to do what you were trying to do using F# (that would not lead to some of the issues you mentioned).

Without sharing the code, I think the blog post is just not making the point very strongly.
Tomas Petricek
Sigh... If you're trying to write F# the way you way you write C# then yes, C# is better, well done.
Comments are closed for this post.