It took me some time to get my head around F#. I had no experience with functional programming and failed twice to pick it up. I persevered; and third time lucky, it started to make sense!
I became a huge fan! Being part of the .NET Framework made it feel fairly familiar and more likely we could start to introduce it at work (we’re primarily .NET devs). Options instead of nulls; immutability, pattern matching, DUs, loads of stuff that looked like it would solve problems we have every day (especially the nulls - we have a > 200k LoC inherited legacy codebase that started life in .NET 1.1 to fight with).
I gave a talk to colleagues who were (inexplicably!) unconvinced, so I gave another one a little later and soon after one of my colleagues arranged working through F# Koans as a team; and the wheels seemed to be moving.
Since we’re busy as ever; F# sort of fell to one side. We were all busy working meeting deadlines; and as a team we weren’t confident enough in F# to pull it into production. The team were even less convinced about F# after I declared PowerShell to be an annoying crock of buggy junk that gets no responses to bug reports, when I’d been so enthusiastic about it months earlier. They expected I’d be announcing F# to be a big failure soon too (oh, the irony of this blog post!) :-/
Fast forward a few months; and I’m charging along again. I got the latest F# up and running on the work build server. Production are up to .NET 4.5.1. I set up an internal NuGet feed and extracted some simple libraries from our main products solution into NuGet packages for easy replacement. Everything is ready to start getting small F# libraries into the main product, allowing the team to get more familiar with writing and reviewing F#! :)
So, what’s the problem? Get to it already!
Well; once we take the dive; it’s hard to go back. This means I’ve been thinking more about it this week than previously; and I’m now starting to wonder if F# is really ready. There are a few little things that quite bug me…
- IDE support even in Visual Studio 2013 is absolutely poor. Basic things like document formatting and refactoring are missing. The community have worked hard on improving this somewhat; but I hit serious bugs (edit: this was fixed within 2 days; kudos!) in their extension within minutes. We spend a lot of time in our IDEs; we need first class support; and F# is miles off.
- Options are great; nulls are bad. But because F# runs on the CLR; nulls are not gone. This means we now just have two different types of null; the bad one, and the good one. I’m on the fence about whether this is really an improvement. Even if you have the luxury of being F# for all of your own code; the BCL is riddled with null returning/expecting methods.
- F# was completely missed from Roslyn. I understand the reasons for this; but with this new “open” Microsoft; there’s still no word on whether this will happen. If it doesn’t; it means F# will miss out on a new generation of tools being built on Roslyn (for example, Code Diagnostics/Fix support).
- There’s little info on what’s coming in the next version of F#; yet we know quite a lot of language features coming in the new versions of VB and C#. It feels like C# and VB are charging forwards at a much faster rate than F#. Do we want to get off the fast train and board the slow train?
- Hiring developers is already very hard. Do we want to limit the pool of available candidates significantly (and take the increased salaries that come with the harder-to-find skills)?
Scott Hanselman was right; programming is hard, but apparently not just the writing of code!
I’m sure use of F# will continue to grow at our company. Both myself and the other team leader are both big fans. However I think the journey will be much slower and more cautious than I’d originally hoped.
Don’t take this article as a bashing of F#; I’m still a huge fan (both of F# and general FP ideas), but I think it may be some time before it’s the obvious choice to make.