Project Springfield is a fuzz testing service for finding security critical bugs in software. William Blum, principal software engineering manager on the Springfield team at Microsoft Research, explains how adopting F# helped the team build the cloud service.
Conciseness is often cited as one of the main benefits of using F#. Blum provides some statistics from Project Springfield:
In order to remove some legacy dependencies, we ported a Perl script to a 37% smaller F# program. In a separate effort we ported 1,338 lines of PowerShell scripts to just 489 lines of F# (2.7 times smaller). In both cases, despite the code size reduction, the resulting F# program improved logging, readability and reliability (due in part to static type checking).
Rachel Reese, software engineer at Jet, made a similar statement about F# conciseness while explaining why the e-commerce company chose F#:
So, we started building two solutions: a C# solution and an F# solution, to see where they would take us. In the end, we chose to stick with the F# path. The main reason: we were able to deliver the same functionality with far less code. This clearly eases maintainability and reduces bugs.
Code correctness is also mentioned often by the Springfield team and F# users in general. For example, null references, also known as “the billion dollar mistake”, are not allowed in F#. Missing data is represented using the Option type, where a value can be either Some valueOfAVariable or None.
Discriminated unions are not limited to the Option type. Complex objects can be expressed and then used in pattern matching expressions. The snippet below shows an event type and the function to dispatch it. Blum explains that the code is garanteed to handle all cases as it’s enforced by the compiler.
type CustomerId = System.Guid
type EventType =
| MsgType1 of CustomerId
| MsgType2 of CustomerId * string * int
| MsgType3 of CustomerId * string * int option
// Handle the message using pattern matching
let dispatch msg =
match msg with
| MsgType1 -> ...
| MsgType2 -> ...
| MsgType3 -> ...
F# also adds the possibility to validate dynamic data sources with type providers. Type providers enables validations on data sources such as SQL databases or JSON to be done at compile time instead of execution time.
Springfield allocates compute resources dynamically, therefore it needs to generate JSON parameter files at run-time; a task that can be error-prone. With F# Type Providers we can statically verify at compilation time that our generated template parameters are valid. Because our ARM templates constantly evolves, this tremendously speed-up development and debugging time.
The Springfield team also adopted F# for scripting. The REPL environment, F# Interactive, provides a way to execute F# scripts without prior compilation, an expected feature for scripting languages.
Another advantage of F# scripts is that they are statically type-checked, an unusual thing for a scripting language! In practice this yields huge saving in debugging time. Errors like typos in variable names or incorrect typing are immediately caught by Intellisense inside the IDE. Refactoring code also becomes a piece of cake. This stands in stark contrast to the fragility of PowerShell scripts experienced by our team.