There are several reasons why I don’t like F# very much. Originally, I tried to categorize these reasons objectively and logically, but the reasons are subjective and overlap, and are all related to each other. But here they are, as best as I can explain, along with some comments.
1. F# just doesn’t feel right.
This is purely subjective, but it’s a huge factor and is an absolute deal-killer for F# for me. Some programming languages, like C# and C, just feel right to me and working with them comes naturally. Other languages, like R and classic Visual Basic, feel neutral to me. But some languages, including F#, Prolog, LISP, and SQL, seem to fight me rather than assist me.
2. F# has a tiny user base.
I did a quick search on the day I wrote this post at a job aggregation site and found 109 job listings that mentioned F#. There were over 34,000 job listings that mentioned C#. And at MSDN Magazine, where I’m the Senior Contributing Editor, our F# articles get very few reads. The tiny user base means there is relatively weak community technical support on sites like Stack Overflow, compared to mainstream languages. Additionally, unlike other languages with relatively few users (such as R), there’s no real motivation for me to adopt F# from a career point of view, because of the very limited job opportunities.
3. F# has no compelling technical advantage.
Some overly zealous F# fans claim that F# can do things that general purpose languages like Perl and C# can’t. This all depends on how you define features of languages. But more reasonable F# proponents usually state, correctly, that F# isn’t intended to replace languages like C# and that F# doesn’t have any unique, magic capabilities. So, there’s no technical reason for me to use F#, and the cost of context switching between the primarily procedural C# and the primarily functional F# is a huge price to pay.
Obviously, one reason why I’m more comfortable working with C# than F# is that I use C# more often. I learned programming using K&K BASIC and C. F# works at a higher level of abstraction than C#, meaning F# is further away from the machine language instructions that all languages ultimately translate to. When I write C-family code, I have a very good idea of how that code will be translated down to machine language. For me, not so with F#.
I don’t like the terseness of F#. Much like Perl, I find myself writing slick, concise F# code, then I look at that code a month later and have difficulty understanding my own code. In a related issue, I am absolutely not in favor of type inference. When I code, I want to specify exactly my data types.
I understand the advantages of functional programming in general, but I can write C# or Java code using a functional approach if I choose to do so. I strongly suspect that the preference for functional programming vs. procedural programming is an inherent personality characteristic in some way, sort of like left handedness and right handedness. This could explain why programmers who like F# really like F#, and vice versa.
There’s a psychological “don’t be a COBOL programmer” issue. Technology is constantly advancing but there are a few — very few — engineers and researchers who have an attitude along the lines of, “Technology X works great and I don’t need to know anything new.” So, there’s pressure to always learn the latest and greatest new programming language, because nobody wants to be labeled as the old guy who can’t change with the times. Well, it’s true that it’s important to stay current, but just because a language or technology is new, doesn’t automatically make it better. Sometimes a new technology is just a solution in search of a problem. A few irritatingly vocal people in the F# community implicitly try to guilt non-believers into F# adoption. This false you-must-learn-F# argument may persuade inexperienced programmers but that tactic just annoys experienced engineers and researchers.
I have no issue with any developer or researcher who likes F# but in my opinion F# will always be a niche programming language like Prolog or LISP.