Why F# for the Enterprise

/

I have gotten bit by the F# bug lately. After helping to release the F# portion of Exercism I've started to enjoy more and more of what F# has to offer. Of course, F# is a sort of "hybrid" language where you can do object oriented and procedural programming if you make it that way, but out of the box it's trying to get you to go more functional.

Several folks have posted as to why learn F# in the first place, but I figured I'd give some reasons why I think F# would be great for scenarios inside enterprise applications. While a few what others have mentioned as good reasons to learn F# in the first place, I believe these would also be the top reasons for enterprise development.

What's wrong with the current enterprise solutions?

Well, nothing, really. Of course, just because one solution works doesn't mean it's the most productive or easiest to maintain. For example, CSS precompilers like SASS and LESS do this with plain CSS stylesheets.

Why not use something that makes our lives, as developers, easier and helps to bring back the fun in developing again?

No More NullReferenceExceptions

While the above always tends to make me laugh, I'm quite sure each and every developer has fixed a production defect that involved this error. 

In F# there are is no thought of "null". You'll even get a compiler error if you try to use "null" in a pure F# program. For example, take a peek at the below code:

We're just defining some record types - Person and Employee - and let binding the Employee record with some values. Now, what happens if I set Person to null?

The compiler won't even let us try that...

Trying to assign null to a record type.

So this shows that, in pure F# code, the compiler won't allow us to set records as null which greatly reduces, perhaps even eliminates, NullReferenceExceptions.

What if we still need null?

There are some exceptions where F# will allow you to use null. Both of which involve using the .NET libraries.

  • As a parameter when calling one of the .NET libraries.
  • Handling if a call to a .NET library returns null.

Even using null in these scenarios can greatly reduce the NullReferenceException occurring in your application. To me, that's just one less thing I need to worry about.

But I still need it in my F# code

No worries! The language has you covered on that aspect as well. Allow me to introduce the option type. This is used if a value might not exist.

Let's take a small example of a bank account.

If the account isn't open yet or has already been closed, we don't expect a value. Otherwise, we do expect some value.

None vs null

How is this different than assigning to null? Remember that None is an option type. Because of that, the compiler will help us out if we may have missed anything. For example, in F# you can do pattern matching. Let's see how we can use pattern matching with the option type.

Good to go there. But, what if we happened to miss a match on None? We'll get this warning:

Pattern match warning.

Units of Measure

Units of Measure allow you to explicitly type a certain unit. F# does have predefined unit names and unit symbols in the Microsoft.FSharp.Data.UnitSystems.SI.UnitNames and Microsoft.FSharp.Data.UnitSystems.SI.UnitSymbols namespaces.

For example, say we wanted to use meters. Instead of assuming our application is using meters throughout all the calculation, which has a probability of being converted to another unit but still being represented as meter, we would just need to do the following:

Microsoft has included a few units of measure for us, as mentioned earlier, but we can definitely create our own. Say we had an application that dealt with different types of world currencies. We can easily define them as units of measure.

Now, what does this do for us exactly? Let's try to convert how many euros are in a dollar amount.

The first method we defined works just fine since we're using the units of measure. However, the second method generates a compile error since it can't infer what type "0.74" should be.

Since a unit of measure is typed, it will generate compile errors and reduce the amount of defects your application can cause due to a mismatch of units. This type of error does happen in real world applications...even to NASA engineers.

Type Providers

Type providers in F# is essentially a way to access all sorts of data. There are quite a few of them all ready for you to use now.

Just the SQL type providers alone are worth it for enterprise applications. Even better, you can even use them to access Entity Framework and LINQ to SQL.

Another important one that may be of great use to enterprise applications is the JSON type provider. 

Type providers provide an easy way to consume data within F# and, if you'd like, use C# to handle that data.

 

The above are just a few reasons of why I believe F# to be of great use to developing enterprise applications. Using the above, the risks of error would be greatly reduced and productivity would be increased. I know I'll be doing more F# in my applications from now on and I can only see it getting even better in the future as this language evolves.