Why Microsoft F# is worth exploring

Yesterday Microsoft launched a new version of Visual Studio. It's stuffed with new features, has a new shell, and introduces a major new release of the .NET Framework, so there is plenty to take in if you work on Microsoft's platform. In fact, with so many things clamouring for attention it would be easy to give little attention to the brand new language that comes in the package - Microsoft F#. Admittedly the language is not entirely new; it's been around for anyone to try for some time. Nevertheless, it is new to Visual Studio, and giving it the status of a fully-supported language alongside C# and Visual Basic is bound to have an impact.

So why bother with F#? As it happens, I'm writing this from Intel's software conference in Barcelona, where the topic under discussion is parallel programming. We've heard nothing about F# (even in Microsoft's presentation); yet F# is a functional programming language and inherently well-suited to concurrency. One of the key features is that variables are immutable by default, whereas in imperative languages like C# and VB the opposite is true. Immutability makes multi-threaded code much safer.

Here's what F#'s inventor Don Syme told me when I asked him what F# brings to concurrent and asynchronous programming:

There's three things. The first is a real focus on reducing the amount of mutable state in your programming. This means in essence that your mutable state is to be boiled down to the absolute essentials of what has to be mutable. If you do have some mutable state it's local to the user interface thread or local to an agent. But in general you can often completely eliminate the mutable state through this consistent set of functional programming techniques, often by passing some data around explicitly, rather than propagating the data everywhere implicitly by these sort-of global mutable tables. So a focus on immutability first is a major factor.

The second is this Async programming feature which essentially allows you to add lightweight reactions to the system, so you can have many objects waiting to be activated by a callback of some kind, and you can program these objects without doing what's called inversion of control. You can program a series of sequential execution, a series of web requests for example, go to one web site, go to the next web site, go to the next web site and so on, and you can write what we call asynchronous workflows to express this logic which would otherwise be encoded as a set of callbacks all the way through your code. This is extremely important when you're talking about handling errors in a series of asynchronous calls or perhaps accumulating a set of resources across the calls and making sure we clean up file connections and other things that happen during a computational process.

The last thing we bring is an Agent-based programming model built on top of the asynchronous model. This lets you define many hundreds of thousands of agents in memory, in a single process. And this is critical if you're reacting to many different external events such a web crawler having many different i/o requests outstanding at the same time, or processing many different images in parallel.

It's a compelling story; and there are other nice things about F# as well, like the succinct, easy to follow programming style it encourages.

Let me now put this together with a conversation I had yesterday with Intel's Chief Software Evangelist, James Reinders. I asked him about functional programming and he sighed, telling me that yes, languages like F# make parallel programming much easier, but that there was no sign of developers switching to them. In addition, he said, there is so much existing code out there that no functional language can succeed unless it can extend applications written in other languages.

It then struck me how well Microsoft has ticked that box with F#. It is a .NET language, so integrates easily with C# or Visual Basic, and it is presented as a language with which to create libraries for specific tasks, rather than as something you are likely to use for an entire application. It seems to me that it can deliver real value and is well worth exploring.

There's more on F# here; and look out for more from my interview with Don Syme soon.