As an aside to all the NuGet packages you use today (almost all of which can be used seamlessly with F#), this appendix contains a list of popular libraries and tools unique to the F# ecosystem. It’s by no means an exhaustive list of all libraries out there (new libraries are always cropping up), but there should be enough here to give you a few ideas of how to start using F# in new and interesting ways.
First, we’ll cover a whole set of F# libraries that we haven’t touched on yet in this book. But don’t forget the ones we’ve already covered, such as Paket, FSharp.Data, and Canopy! Note that many of these libraries are just that: libraries, not frameworks. They can be used interchangeably in a flexible manner, without forcing you down a specific path. They’re nearly all open source and free to use (available on GitHub and NuGet), and most work cross-platform without relying on Visual Studio tooling.
F#’s unique syntax, scripting, and language features make it a great choice for part of (or to replace!) your build pipeline. The ability to create custom operators enables you to perform some impressive tricks that can replace MSBuild and PowerShell for orchestrating build pipelines.
FAKE (F# Make) is a build automation system with capabilities that are similar to make and rake.
FAKE comes with a large set of helper libraries to perform common tasks, such as copying files, building projects, versioning assemblies, rewriting configuration files, running unit tests—all sorts of goodies. It can, in effect, replace your reliance on a central build platform such as TeamCity and allow you to run builds locally as well as remotely. Builds are made up of tasks, which are arbitrary functions that have a name; these are then composed together using the FAKE DSL into a pipeline, as shown in figure 1.
Figure 1. An example FAKE build pipeline
One of FAKE’s great strengths is that it runs as simple F# scripts, so you have total control; if you need to make your own custom build task, you can easily do so—just write some F#! In addition, you avoid tying yourself into a particular CI server (for example, TeamCity, AppVeyor, or VSTS). Instead, FAKE handles your build process, and because you can run it locally, it’s much easier to reproduce problems in your CI build chain; your CI server simply has a single task in it, which is to run the FAKE script.
http://fsprojects.github.io/ProjectScaffold/
ProjectScaffold helps you get started with a new .NET/Mono project solution with everything needed for successful organizing of code, tools, and publishing.
The F# ProjectScaffold was designed to create a framework to support many common features you’ll want in an open source project, such as automated build, dependency management, automatic NuGet package creation, HTML documentation generated from F# scripts, and a full, one-click release process with automatic labeling and versioning to Git.
ProjectScaffold is commonly used for many open source F# projects (including many that you’ll see in this appendix), and the tools it uses are popular and well understood in the community, such as Fake, Paket, and FSharp Formatting. But the build scripts can be complex, so there’s a lot to get your head around.
You’ve already seen how well suited F# is to working with data, but we haven’t covered all the libraries out there. This section covers a few more libraries that can make your life much easier when trying to perform more than the typical day-to-day sort of data operations you’ve seen so far.
http://fsprojects.github.io/ExcelProvider/
As much as you might not like to admit it, Excel is everywhere and isn’t going away any time soon. Sooner or later, you’ll need to work with data that a customer sends you in Excel.
The ExcelProvider is a type provider that sits on top of Excel files. You can then work with Excel files directly in F#, just as you can use the FSharp.Data type provider to work seamlessly with CSV, JSON, or XML files. ExcelProvider has a great deal of flexibility, and you can use cell ranges to work with only subsets of data within an entire sheet; this is great if you have multiple datasets within a single worksheet.
http://bluemountaincapital.github.io/Deedle/
Deedle is an easy-to-use library for data and time-series manipulation and for scientific programming.
Deedle is F#’s equivalent of R’s DataFrames, or Python’s Pandas. It allows you to work with datasets in a two-dimensional frame (think of old-school .NET DataTables) and perform operations on the frame, such as inferring missing cells based on surrounding rows, time-series analysis, groupings, and aggregations. It’s also used within the finance domain for things such as stock tickers and price analysis. The API definitely takes a bit of getting used to, but it’s extremely powerful.
FsLab is a collection of libraries for data science. It provides a rapid development environment that lets you write advanced analysis with a few lines of production-quality code.
If you’re interested in machine learning but thought you’d need to leave the comfortable world of .NET to get involved, this package is for you. FsLab is a one-stop shop for machine learning on .NET. In and of itself, it doesn’t do much; it’s a NuGet package that references a set of other NuGet packages, including the usual data ones (such as FSharp.Data and Deedle), charting libraries, machine learning libraries, and the R Type Provider, which allows you to seamlessly call out to R packages and libraries from F#. It also contains project templates that can make your life a little easier with regard to getting up and running (although it’s not strictly necessary to use them).
https://fslab.org/FSharp.Charting/
Unlike XPlot (which uses Google Charts and Plotly to render visuals), FSharp.Charting uses the charting components built into .NET to create charts, as shown in figure 2. Although the results aren’t quite as flexible as XPlot (nor are they quite as pretty), the API is easy to use, and it has support for streaming and animated charts, something XPlot doesn’t support.
Figure 2. Using FSharp.Charting to quickly and easily generate visual charts
F# is close to achieving an exceptionally good web story. You’ve already seen how F# and functional patterns are a great fit for the web on the server, but what about on the client? F# has two choices here, Fable and WebSharper, that allow you to do just that.
Something that this book has steered away from is F# on the client, or running F# code in the browser. You can’t directly do this, but what you can do with the Fable project is transpile F# into JavaScript, in the same way that you can create JavaScript from TypeScript or Dart or CoffeeScript (see figure 3). The Fable project (and the FunScript project it replaced) do an excellent job of this. The generated JavaScript is not only easy to read, but also maps across many calls from the BCL to JavaScript libraries automatically.
Figure 3. Using Fable’s browser REPL to try out F#-to-JavaScript compilation
A lot of superb work is being done in this area, including libraries that allow you to design web pages in F# by using custom DSLs; developers are already reporting fantastic productivity gains by having F# on both sides of the fence. There’s no reliance on specific Visual Studio tooling, and it works cross-platform. If you’re doing any web programming, you should check it out. Check out http://fable.io/repl for a page that converts F# to JavaScript in the browser—seriously cool!
A fundamentally different web framework for developing functional and reactive .NET applications.
WebSharper is a more mature project than Fable that has the same aim—F# on the client—but tries to achieve this via a more prescriptive framework plus some Visual Studio templates. It’s extremely smart, using its own custom compiler to generate JavaScript from F#, and allows you to write reactive (event-driven) applications entirely in F#.
WebSharper began as a commercial platform, and although it has become free to use now, it’s not quite the same in terms of open source as Fable. The flip side is that it has a team of developers who maintain the project, as well as consultants who offer training, so it’s not necessarily the case that you’ll be on your own if you use it. It’s not the easiest framework to pick up, and being a framework, it’s not only prescriptive but also locks you into a specific way of working.
Elegant. Modern. Powerful. Functional web programming for F#.
Freya is another F#-first web programming framework, just like Suave, although Freya has a different programming model. Both support the idea of composing small bits of functionality together to build larger systems. Freya is actively updated and uses several other libraries to provide excellent performance (in fact, it sits on top of Kestrel, part of the new ASP .NET core framework).
http://fsprojects.github.io/FSharp.Formatting/
F# Formatting is a fantastic tool that allows you to generate HTML documentation based on F# scripts or a combination of Markdown files with embedded F# (see figure 4). Indeed, the documentation states that most F# open source projects are created using this library. It also has support for embedding images, charts, tables, and even source code (with tooltips!) inline.
Figure 4. Using F# Formatting to generate HTML content from combined Markdown and F#
You can use F# Formatting for more than just documentation of a site. You can also use it for generating reports. For example, imagine you want to create a daily report that contains the latest sales figures—no problem. Create an F# script with the F# Formatting library and generate your report as an HTML document. When you’re done generating it, email it off to key stakeholders, perhaps using a FAKE script to orchestrate the tasks!
I spend a lot of time working with cloud applications, and F# is well placed to take advantage of the cloud (something Microsoft is well aware of). If writing multithreaded applications is difficult to reason about, think about the difficulty of writing applications that run across multiple machines across an unreliable network. F#’s approach to immutable data and expressions helps reason about things here!
https://github.com/fsprojects/FSharp.Azure.Storage
The Microsoft Azure storage service provides access to multiple services, one of which is Tables, a cheap, simple, two-dimensional storage system. FSharp.Azure.Storage provides a pleasant F# DSL on top of the table service, with support for easy insertion, updates, and queries of data directly from F# records.
http://fsprojects.github.io/AzureStorageTypeProvider/
The Azure Storage Type Provider gives you a full type provider over the three main Azure Storage services: Blobs, Tables, and Queues. You can point the type provider to a live Azure Storage account and receive IntelliSense over the assets in the account (see figure 5). It supports safe querying over tables (in that it guarantees not to generate queries that the service will reject at runtime), and intelligently generates table types based on the contents of a remote table; there’s no need to create F# records in advance.
Figure 5. Navigating through a live Azure blob storage account in real-time with IntelliSense
https://github.com/fsprojects/FSharp.AWS.DynamoDB
If you’re an Amazon Web Services developer, rather than Microsoft Azure, you can use the FSharp AWS DynamoDB library. It’s similar to the FSharp Azure Storage library in that it’s not a type provider, but rather aims to provide a simple API that takes advantage of F#’s language features to make it easier to work with the DynamoDB storage system.
Integrated data scripting for the cloud—get started with MBrace today.
MBrace is possibly the most exciting project of all here. It’s a general-purpose, flexible framework for distributed computing on .NET. It allows you to wrap arbitrary code blocks—whether they’re accessing F# functions, values, or even VB or C# code—and distribute work across a cluster of machines, before returning with the result. It’s extremely smart, handling distribution of captured values, exception propagation, parallel workloads; there’s even a big-data library that supports LINQ-style queries against massive datasets. The programming model is extremely easy to grok if you understand how async { } blocks work, as it’s effectively the same; you simply replace async { } with cloud { }! There’s support for both Azure and Amazon cloud systems as well as an on-premises model.
When we touched on WPF in this book, it was explicitly left as the domain of C# for the presentation layer, with F# providing the business logic. But that’s not entirely necessary, as F# also has several excellent libraries for working with WPF.
http://fsprojects.github.io/FsXaml/
FsXaml is a type provider that can create a strongly typed view based on an XAML file. In effect, it replaces the need for the code-generation phase used in Visual Studio when working with XAML in C#. Using FsXaml, you can start to create complete WPF applications in F# projects, with full IntelliSense over controls that live in those views. If you already know WPF, this type provider will allow you to continue to work with WPF but in a 100% F# environment.
Although the official documentation is very sparse, the source code repository has some useful samples, as well as a collection of F# WPF templates that you can add to Visual Studio that show larger examples of working with it.
https://github.com/fsprojects/FSharp.ViewModule
The companion project to FsXaml, FSharp.ViewModule, provides a framework for creating GUI applications that adhere to the Model-View-ViewModel (MVVM) pattern that’s popular in the WPF world. The MVVM pattern is typically object-oriented, with changes to your state combined with the INotifyPropertyChanged interface to push changes to the view.
FSharp.ViewModule encapsulates much of this and allows you to focus on working with simple mutable objects with automatic change tracking. There’s also an excellent set of helpers for binding XAML commands to standard F# functions; this abstraction means that you can write code that doesn’t stray too far for F# patterns and practices while still being able to work with WPF views.
Alongside the preceding libraries, a few other miscellaneous libraries, although not necessarily fitting into any specific category, are nonetheless useful and worth pointing out.
http://fsprojects.github.io/Argu/
How many times have you written a console application and needed to parse configuration arguments supplied to it? Argu solves this problem for you. You define a declarative model that represents the possible arguments that can be supplied, and the tool maps the model to the input arguments. There’s support for mandatory and optional arguments, automatic help, and friendly error messages, as well as automatic parsing of types.
http://fsprojects.github.io/FSharp.Management/
The FSharp.Management package contains a set of utility-type providers that you’ll always want to have around when working on Windows with local resources:
File System—Strongly typed access to files on the local filesystem Registry—Strongly typed access to the Windows registry WMI—Strongly typed access to the Windows Management Instrumentation service (see figure 6) PowerShell—Provides the ability to call PowerShell functions and modules directly from F# SystemTimeZonesProvider—Strongly typed access to all time zones in .NET Figure 6. Accessing WMI components through IntelliSense via the WMI type provider
http://fsprojects.github.io/FsReveal/
If you’re fed up with creating presentations using PowerPoint, FsReveal is an easy-to-use tool that can generate web-ready slide decks based on simple Markdown files. You don’t need a full application such as PowerPoint; you simply open a text editor (ideally, one that can preview Markdown), and off you go. Instead of heavyweight tooling, a simple FAKE script converts the Markdown files into a fully interactive website.
Because FsReveal sits on top of the JSReveal library to do most of the heavy lifting, it has all the nice features that JSReveal has, such as speaker notes, support for clickers, animated images, tables, and more. And because it also uses F# Formatting, you can embed code in your slide decks and have it automatically generated in a pleasant HTML web-based slide deck, complete with tooltips!
http://fsprojects.github.io/FSharp.Configuration/
FSharp.Configuration is a set of easy-to-use type providers that support the reading of various configuration file formats:
AppSettings—Application settings (and connection strings) for a .NET config file (see figure 7) ResX—.NET resource files Yaml—YAML configuration files INI—Old-school .ini files Figure 7. Accessing application settings from an app.config file by using the Configuration type provider
Most projects have some form of configuration settings, so you’ll probably be using this package more often than not!
http://fsprojects.github.io/Chessie/
The last project we’ll address in this appendix is Chessie, a ready-made library for working with Result code (code that might be a Success or Failure), also known as railway-oriented programming. F# 4.1 will have a built-in Result type, so I imagine that Chessie will change at some point to build on top of that. For now, it contains a complete Result type along with many useful helper methods, such as mapping, binding, and so on—in effect, the same sort of behavior that you can achieve with the Option module.
If you find that Option isn’t quite enough for you, and you want to encode error details along the way rather than simply throwing away the None path, Chessie is a ready-made library for you (and one that has some good documentation).
Now that you’ve looked at all of these libraries, many of the points I made at the start of this appendix (and indeed at the start of the book) should now become clear about the F# toolchain:
No reliance on custom tooling in Visual Studio Emphasizing a code-first approach to development Type providers instead of code generation Simple, independent libraries that can be composed together Open source, community-led projects With that in mind, let’s compare a typical tooling stack that you might be used to today, and an alternative stack that an F# developer might choose to adopt. Table 1 details the comparison. Table 1. Comparing alternative technology stacks on .NET and F#
| Function | Microsoft stack | Pure F# stack |
|---|---|---|
| Complex build process | MS Build custom tasks | FAKE script with MSBuild |
| Continuous integration | TeamCity, TFS pipeline, etc. | FAKE script on TeamCity, TFS, etc. |
| Dependency management | NuGet | Paket with NuGet + GitHub dependencies |
| Project system | Solution and projects | Standalone scripts and/or project + solution |
| Ad hoc processing | Console applications | Standalone scripts |
| Test libraries | xUnit, NUnit | Expecto, QuickCheck, Unquote, FsTest |
| SQL ORM | Entity Framework | SQLProvider |
| SQL micro-ORM | Dapper | FSharp.Data SQLClient |
| Server-side web | Full-blown Web API project | Bare-bones NET Web API OWIN, or Suave |
| Front-end web | ASP .NET MVC, TypeScript | F# with Fable |
| IDE | Visual Studio | VSCode, Emacs, Visual Studio, and so on |
The main point is that although you can definitely continue to work with virtually all of the technologies and tools in the Microsoft stack in the F# world, you’ll also find an alternative stack on the right-hand side, which more fully embraces the points previously made, with the overall aim of trying to improve productivity (and developer satisfaction!).
Nothing says you must pick everything on one of the two sides; the key takeaway is to understand that there’s more than one way to solve many of the problems that previously you might have assumed had only a single option.
This appendix has hopefully given you a whirlwind tour of some of the tools and libraries that weren’t introduced in the book, and shown you that there’s a wide-ranging ecosystem in the F# world that takes full advantage of its features, in addition to the standard set of .NET libraries you’re already familiar with. Undoubtedly, other libraries could just as easily have made this list, and you should investigate finding new libraries through the community on a regular basis.