As I’m sure, so many other people have also found their lives disrupted due to the pandemic and other world events; I’m just getting to the point where I can think about blogging again due to getting a sense of normality back. One of the things I have been doing is continuing my journey with functional programming languages by looking into F#. I’m not entirely sure why but there’s something alluring about F# that appeals to my style of development. I’m hoping to give you a quick overview of some of the things that interest me about F# and then maybe create some additional postings going over F#’s syntax and functionality with some example code.

I have always had F# on a list of languages to learn and even talked about it in my “Learn Functional Programming” posting back in January of this year. F# falls under the ML family of functional programming languages, offering similar syntax to other languages in the same family such as OCaml, Haskell, and Elm, so F# is in good company. In contrast to the Lisp family of languages, ML languages are typically strongly typed. I think this is one of the appeals of F# for me, having worked in both strongly and weakly typed languages before. I always tend to lean towards strongly typed languages for the guarantees they have to offer, especially when working in a codebase that has multiple contributors. Luckily F# can infer your types for you, making type declaration almost unnecessary. This is the best of both worlds and has been enjoyable to work with.

F# is an open-source language that runs on top of the .NET platform alongside other languages like C# and Visual Basic. Because F# exists alongside the other .NET languages, one of the design goals is being interoperable with different languages. Due to this goal, F# is not a pure functional programming language and even allows using object-orientated programming when needed, which helps when interacting with C#. This design decision will enable companies to adopt F# without the need to rewrite everything. I have heard many companies using F# alongside C# for things like domain modeling and data processing, something that F# really excels at. This gives the developer the ability to use the best tool for the job when tackling problems.

I mentioned that F# is good at domain modeling, and in fact, there is an entire book on the domain modeling with F# from Scott Wlaschin called “Domain Modeling Made Functional”. F# includes many things that really help with modeling a domain and functionality to make data processing of the domain you created simpler. F# has something called Discriminated Unions, which allows you to model different states of items within the domain. This also opens up the use of Optional types (or “Maybe” from other functional languages), which is used when you may have something or nothing, you can think of this in the same way of a null but much more powerful. Optional types allow you to avoid getting any null pointer exceptions that you find in other languages. All of this also works with pattern matching that makes processing the many different states of an object quite simple but also checkable by the compiler to ensure that you did not miss something. Also F# is immutable by default with built-in optimized data structures that support this behavior. This is a vast topic condensed into a single paragraph, but I do hope to create some other postings about this, because I do believe it’s one of the most powerful aspects of F# that does help with the creation of a high-quality system.

Why you should use F#Phillip Carter

Getting started with F# is quite simple because it comes with .NET Core automatically and Visual Studio which also supports working with F#. Chances are if you’ve done any modern development with C#, you’re already all set to start experimenting with F#, and even if you haven’t there’s not too many steps needed to install .NET Core. I can definitely see this being overlooked as a huge advantage, but this is something that lowers the bar of entry to trying F#. When you look at other functional programming languages, I really can’t think of another with these two elements of being easy to install and having an officially supported IDE. Of course, you’re free to use whatever code editor you wish, there is excellent support in JetBrains Rider, VS Code, Emacs, and Vim. For most projects, I have been using VS Code with the Ionide plugin and have been very happy with this setup. I find myself getting into a similar flow of writing code that I did with Clojure, sending it to be evaluated at the REPL and working with it interactively.

Thanks to the excellent work that has been put into the .NET platform, F# can be used to create many types of different applications. Generally anything you can do in C# can also be done with F#, this includes creating console applications and even web servers using ASP.NET. F# is also able to develop mobile apps for iOS and Android devices like C# with Xamarin. F# can be used to create web applications in JavaScript or using WebAssembly. This last part on web applications is something I want to dig into a bit more because it’s the one that most intrigues me but also shows some of the nice potential F# has.

There is a project called Fable that leverages Babel to convert F# into JavaScript, allowing you to create web applications using F#. If you’ve done web application development before, you most likely have used Babel as part of your build system to compile one language into JavaScript (even if that language is already JavaScript). Fable gives you all the tools to create F# code that can work with the HTML API and other JavaScript code. Everything in F# is typed and checked by the compiler for correctness before being converted into JavaScript. It is similar to what you’ll find when using TypeScript. To take this one step farther, people have started to leverage ideas from the Elm Architecture or “model view update” to create an F# library called Elmish. As Elm and F# are both ML languages, there’s a lot of similarities except F# not being a pure functional programming language it’s able to interact with JavaScript libraries more simply then Elm can. Elmish is leveraging the popular web framework React for its virtual DOM implementation. Elmish also allows you to work with preexisting React applications enabling you to reuse components. Both Fable and Elmish have an active community that keeps working to continuously improve the ecosystem for developing web applications in F#.

I also mentioned WebAssembly, which is one of those technologies that hopes to change how we develop applications not only for the web but many other platforms as well. In the case of web applications, WebAssembly will allow you to write code in whatever language you want and let it run in a browser. Right now, there is limited support for the languages but Rust, Go, and C have been pushing the way, along with C#’s Blazor which lets you create web applications using WebAssembly. The community has extended Blazor to create a project called Bolero that will let you use F# but also leverages a lot of the elements from Elmish so you are able to use the Elm Architecture for creating your application.

F# allows the development of many different application types, from console to web applications. A lot of the flexibility is due to the .NET platform and the active support of the F# community to support the various projects. F# does provide some exciting ways to develop software like using domain modeling and optional types with having a compiler that can infer your variable types and reduce the number of run time bugs. Because of all these interesting things F# has, I’m looking forward to learning more about the language, ecosystem, and the community. I hope this posting has intrigued you enough to look into F# and knowing that the barrier for entry may be lower than other languages. I would encourage people to take a look. I hope to continue blogging more about F# and talking about the interesting aspects of the language.