Let's look at some myths around the F# language and challenge them, based on our experience as a consultancy using F# almost exclusively for several years. We've built several of our own F# projects, guided other customers in building theirs, and trained people in using F# and related technologies like the SAFE Stack.
1. F# is hard to learn
As always, how difficult it is to learn anything depends a lot on your background, so let's consider some different backgrounds.
C# users find the F# syntax very unfamiliar at first, but they are familiar with .NET and its libraries, which they will likely also use heavily in F#. If they make heavy use of object-oriented or imperative styles, they can take some time to become comfortable with functional-first, immutable programming. If they already use C# in a relatively functional style with the latest language features, they often quickly learn how to extend this style further into idiomatic F#.
My own experience is that I started my developer career by joining a C# team. I learnt C# on the job and simultaneously learnt F# in my own time. I found F# to be a lot simpler in its idiomatic usage, mainly writing functions and not classes. I found fairly soon that I could solve problems in F# with less ceremony and less code than with C#.
Generally speaking, we've found that F# is no harder to learn than your "average" non-functional language.
2. F# is only for hard problems
In the past, F# has had a reputation for being mainly used for "maths and science". We have heard people say things like "I don't need to use F# because the problems I have aren't hard enough".
And besides, writing any software that meets the changing needs of the real world while keeping the codebase maintainable is actually a hard problem!
3. You need to know category theory to use F#
Pure functional languages like Haskell often make use of areas of mathematics like category theory. One example of this is the much dreaded or loved monad. The Haskell community tends to communicate using these concepts.
F# on the other hand is functional-first, not purely functional, and it has a different culture among its users. Even though category theory concepts are used to some degree to help give F# a sound and correct design, F# programmers don't need to know about them in order to write good F# or to read the vast majority of F# code. For example,
Option may be a monad but I don't need to know or care about that to use it or talk about it.
F# does have several features that go above and beyond traditional object-oriented programming, like discriminated unions and computation expressions, but they are designed to be intuitive and usable to a programmer's mind.
4. F# code must be slow if it's immutable
F# encourages you to avoid mutation and using immutable data structures. This may be faster than you think if you haven't worked in a functional language. Immutable data structures can be designed in a way that makes them quite fast for certain operations, so you can get their benefits without much cost. See our post on Immutable data structures for more details. For general business app code they are often fast enough.
However, there are always some domains where mutation is needed to get enough performance. F# also allows you to use mutation where necessary, ideally in a limited scope.
5. F# is only for the back-end
6. Not enough people use F#
When considering this statement, we should ask "Not enough for what?". It's true that F# is still quite niche compared to the top 10 languages, but how much popularity do you need to use it effectively in your projects?
On the subject of hiring, there are fewer developers with a good knowledge of F# compared to the most popular languages. However, we have found there are many good developers who would love the chance to use F# at work, with varying degrees of experience with it but a strong willingness to learn, and therefore finding good candidates hasn't necessarily been more difficult.
Popularity isn't always a good thing either. Consider the competitive advantage that you gain from using using any technology that improves your code and your software, compared to other people that aren't using it!
We've been using F# for long enough to hear these myths crop up several times, and hope this account of our experience dispels them in a balanced way.