For many developers, working in the Microsoft .Net framework means using C# or perhaps Visual Basic. However, there’s a new language from Microsoft Research which is generating a lot of buzz in the developer community: F#. Even though it’s new, F# is heavily inspired by other, much older languages like ML which turned 42 this year. We decided to give F# a chance and discovered that it allowed our developers to work faster, cutting our development time and also helped them write better quality code, which led to far fewer bugs being shipped.
Faster development time is an often promised and under delivered objective. We found that our developers were much faster in F# than C# because F# takes many of the industry best practices like immutable values and side-effect free functions and makes those practices the default. In most cases, C# can do all of those things too but they require extra effort from developers. By making them the default, F# has made them free for developers to use.
The hidden benefits of Microsoft’s newest language
This is a general theme for the language in that the default behavior is the right one.
F# actively tries to push your developers into a pit of success instead of forcing them to expend extra effort to get there. Of course, since F# runs on top of the standard .Net Framework, all of the API’s your developers are used to from C# are available as well. You can even write new code in F# and have your existing C# (or Visual Basic) code call it.
A great option for existing projects
The effects of better defaults don’t just make it easier to write code, they make it easier to write the right code. F# encourages you to make your code easy to test from the get-go. Test Driven Development (TDD) can be cumbersome to implement in C# but in F# it’s a breeze thanks to things like immutable values and side-effect free functions. In addition, the F# compiler exhaustively checks your code to make sure you’ve covered all of the cases. Together with the strong type system, this allows you to model the business domain and be sure that you haven’t missed any important details. We found that once our code compiled, it was generally correct. We found that our F# code has generated far fewer bug reports than other components in our system even though it is larger than many of them. Of course this means that we spend less time fixing issues and more time shipping features.
It’s not often that you find something that will increase your development speed while eliminating bugs and have it actually work. We found while developing HighGear, our no-code workflow platform, that F# did both. As a result, we are continuing to write more code in F# and we are continuing to find that it leads to both higher quality code and fewer bugs. We would recommend investigating F# to any company interested in using the Microsoft .Net framework.