I have never had an opportunity to use F# in a commercial environment. I have been a developer in the .NET arena for 8 years and as yet have not been able to come up with a decent enough excuse to use it. I find F# fascinating and the more I read about it the more intrigued I am to see how it would stand up in a commercial .NET environment. But, like I say I have never had a reason strong enough to persuade myself to use it. Maybe I don't understand the pros and cons enough. Maybe Idon't understand the practical benefits.
In this article im going to attempt to explore what are generally advertised as the pros of F#. From what I do understand, people sell it based upon the following features:

Immutability by default

Discriminated Unions

Pattern Matching

Lets go through each one.

Immutability by default

Immutability is an object or value that cannot be mutated. A classic example in C# is the immutability of the string type. Because string is immutable if you are doing many concatenation operations it is beneficial to use the StringBuilder because the StringBuilder is mutable. To put it another way if you concatenated two immutable strings the result is a new immutable string. Changing a StringBuilder contents does not create a new StringBuilder so can be more memory efficient.

Mutability isn't always a good thing though. Immutability guarantees thread safety. If your value is immutable you can be sure that if there is another thread using the same value it cannot change the value from under you. Immutability is possible in C# but it is not implicit. I also means there is a lot of pattern code written to make types immutable.

So how does F# deal with keeping values immutable. It seems that the compiler can do most of the work. Lets use a simple example to illustrate this fact.

Notice that we created a new int called i (weird syntax I know) we then create another new int and assign it the value that i has. Then we change the value of i. Is the result what you expected? I made j the same as i. Now I understand that int is a value type and is immutable and the line int j = I; is actually creating a new int and taking a copy of the value of i and changing i after this fact will have no impact on j whatsoever. But what if I was learning C# does this make sense? Maybe, maybe not. Now let's take a look at the equivalent in F#.

This doesn't even build. The compiler tells me that j is immutable. The fact that j can't be changed after I've assigned it the same value as i is highlighted at compile time. The compiler is making sure that i == j. There is no doubt to any F# developer that i is immutable and that this operation is actually not allowed.

Discriminated Unions

Something that F# supports natively that C# doesn't is discriminating unions. They are similar to C++ union types with one key difference, they are type safe and immutable. See this post for a good introduction to F# discriminating unions.

Discriminating unions can be used to represent simple object hierarchies and the classic example is a Shape. From MSDN:

type Shape =
// The value here is the radius.
| Circle of float
// The value here is the side length.
| EquilateralTriangleof double
// The value here is the side length.
| Square of double
// The values here are the height and width.
| Rectangle of double * double

this doesn't really give us much. It gives us a more concise definition but the usage is the same.

another suggestion is that they can be used to represent heterogeneous data. This is interesting. This isn't easy in C# and it seems F# gives us a nice concise way to do this.

You can see here that this Discriminating union could be used to model log entries in a log file. Although this is possible in C# the resulting code would be much more verbose.

Another suggestion is that discriminating unions can be used to represent tree structures. Again this isn't easy in C# and F# gives us a clear and concise syntax for modelling tree structures. From MSDN:

type Tree =
| Tip
| Node of int * Tree * Tree

Again this is very concise. It is possible to have this type of data structure in C# but it will be a lot more verbose.

So with discriminating unions we have a very powerful tool for representing heterogeneous data. But is it the best out there? Should I choose F# over some other technology? I'm not convinced yet.

Pattern Matching

Pattern matching in F# is, at first glance, similar to a switch statement in C#. Dig further though and it is much more powerful.

Pattern matching actually returns a result. The result can be of any type (as long as they are the same type). So given any value we can match on any match expression we like and return any data we like. Again from MSDN:

From my pretty shallow review of these "pros" you can easily see that discriminating unions and pattern matching would be very powerful tools for processing heterogeneous data. That married with implicit immutability enables a highly parallel solution.

So what kind of problem could this solve? Well as I touched on previously, it looks like it would be a good fit for defining data flows. And, because F# makes it safe for us to operate in a parallel environment, high volumes of data could be handled.

Objects

I understand that F# is a fully OO enabled language too. I can never see myself writing OO code with F#. It seems like F# has went out of its way to remove the need for hierarchies of objects. After all it is a functional language. It seems to me that F# is an OO language because it needs to integrate with the .NET platform, which is strongly OO. It doesn't make sense to write all of our code in F# so we will need an OO "interface" in our F# modules so that our chosen .NET OO code can make use of it properly.

I suppose you could look at this like another selling point. Are there any other functional languages that can slot into a largely OO architecture as easily as F# advertises it can?

So maybe the next time I am tasked with processing a large amount of heterogeneous data maybe now I can be confident enough to use F#. And, while I do I will be listening to this -

F# Song

Nice read, I just passed this onto a colleague who was doing a little research on that. And he actually bought me lunch because I found it for him smile Therefore let me rephrase that: Thanks for lunch! "The capacity to care is what gives life its most deepest significance." by Pablo Casals.