Unit 5. The pit of success with the F# type system

We’re making progress now! We’ve covered F# syntax, FP principles, functions, and collections—almost there! This next unit is the last one to focus on core language features in F#—remember that this book covers a core subset of the F# language, after which you’ll have some fun writing meaningful applications that use a variety of frameworks and libraries.

A common phrase you’ll hear in F# circles is the ability to “make illegal states unrepresentable.” In C# and VB .NET, we’re used to the notion of proving that an application is correct through, for example, unit tests and console applications. In F#, we still use unit tests, but to a far smaller degree. Part of that, as you know, is because of the REPL. But another reason is that the F# type system allows us to represent business logic as code so that if your application compiles, it probably just works. Sounds crazy, right?

In a more tangible sense, this unit is all about modeling program flow, domains, and business logic in F#, covering a set of language features that work together to provide a much more powerful way to reason about what your program does than simple if/then statements and inheritance hierarchies do.