What the F#!
In a previous post I have explained my motivations for functional programming. It’s no secret I love F# because F# makes me sleep better. In this post, I would like to discuss some different aspects of F#.
F# is gaining independence from .NET
F# is mostly known to the developer community as the small ignored brother of C# running on the .NET platform. However, what is less known about F# is that it has come to a level to be .NET independent. Thanks to Fable, today F# can be considered as a complete replacement of TypeScript. Yes, people do write full-blown SPA, React, Svelte applications by using F# instead of TypeScript. If you think Fable is just a transpiler, think again: https://github.com/kunjee17/awesome-fable . I would say Fable is on the way being an ecosystem by itself.
There is also a new prototype target for Fable that allows F# code to transpile to Python developed by Dag Brattli.
F# also works as on WebAssembly with Bolero which is still based on .NET. And not to forget another F# web platform called WebSharper from the same people who developed Bolero.
This somewhat puts F# in an interesting position as historically most dotnet has been languages are managed by Microsoft. But Fable simply liberates F# from Microsoft and .NET.
The F# fanboys
You might have heard “one of those guys” like me who is talking about how great functional programming and/or F# is. And from that point, it looks like below
I know it’s annoying, however, let’s look at it from the side and this is how an F# developer feels when he or she is suggesting you using F#:
Microsoft’s and community’s stance
From Microsoft’s point of view, F# is actively supported and maintained. There are Microsoft developers actively fixing things and adding new features however as a general Microsoft’s point of view .NET == C# and that is that. From .NET developer community’s point of view, things are even worse. Since all Microsoft docs and tools geared towards C#, adding up unfamiliarity with the functional paradigm, most people follow C# way and completely ignore its little brother F#. I still think this is a missed opportunity for the .NET community. For example, let’s look at the excellent server side F# web framework Giraffe. While C# and asp.net developers are busy memorizing the Microsoft way of handling requests, learning what attributes to decorate their classes and members, the F# developers who use giraffe, simply rely on functional composition:
let app = route "/" >=> setHttpHeader "X-Foo" "Bar" >=> setStatusCode 200 >=> setBodyFromString "Hello World"
As HTTP processing is usually treated as a pipeline by itself on the server-side, it’s an excellent target for functional programming. Just like lego, plug-in your pipes, and you are good to go.
Furthermore, most developers worry about if they could find an F# job whereas companies who consider making the switch worry if they could find an F# developer. As of today on linked in there are approximately 700 F# jobs and even most of these are not F# specific rather than they are like “C# or F# developers wanted”.
And most non-.NET people are not willing to touch anything related to Microsoft even with a 10 foot pole. (Of course, the major exceptions to this are TypeScript and Visual Studio Code which both are widely popular). The Functional programmers’ camp also dismisses F# at sight blaming it’s not like Haskell as in for example F# does not support type classes.
Couple of unique features of F#
I am not going to talk about the features of F# but just wanted to highlight a couple of them.
The first one is the file order. Please look at the below photo:
In F# the order of the files matter. It is somewhat a disliked feature by the newcomers, but it makes the dependencies immediately visible. So the code in the top file has no dependency on any others below and the 2nd file from the top only depends on the first. When you open a project which you are not familiar, file ordering helps to find your way.
The second one is Type Providers:
Type providers are somewhat code generators but they do that non-intrusively. Very roughly similar to LISP style macros they expand at compile time. Type providers make it very easy to discover HTML or JSON documents read database rows, file system, and discover DDL and rows within the coding screen without leaving your editor. And everything becomes so type-safe.
Develop fantastic UI apps with F# and Elmish
Well they say seeing is believing, so let’s see how well F# handles UI development. While React devs on Facebook trying to solve the state problem over and over again by using hooks and perhaps new experimental recoil and contexts IMHO, all are horrible options as they encourage rendering code inter-mix with business code reminding me asp.net web forms times where you could write your SQL statements right into the page itself.
F# developers have ported elm architecture to something called elmish and it flourished well among F# community.
Here’s a list of things you can do with Elmish as you can write your business code once and port it to any UI platform below:
- React: Elmish React
- Windows Desktop: Elmish WPF
- Gaming: Xelmish
- Cross platform UI: Avalonia.FuncUI
- Mobile development: Fabulous
- Terminal: Terminal.Gui.Elmish
- Web Assembly: Bolero
They all share the same single architecture: Elmish. So you can write your code for one and port it to another.
Getting started and some resources
If you want to get started to F#, the first place you should check out is F# Software Foundation
As you can see FSharp Software Foundation offers mentorship programs periodically, which means you can have a free weekly 1 on 1 session with an experienced F# developer! As of today the program is open for people who want to have an F# mentor or want to be an F# mentor. You can apply from here.
If you are a C# develeoper and you want to start functional programming with F# this is the go-to book: Disclaimer: I do not know the author nor I am affiliated with the publisher by any way
Although the book is mostly about C#, it will show you how painful to do functional programming with C# and only perhaps then you can develop some love for F#. Having that said it will also help you to understand some more new coming but confusing features of C# 9 like Records and Pattern matching. If you think C# records are for immutability, no they are not. They are for Value semantics and referential transparency.
To try F# right away you may use the following links:
When you are unfamiliar with F# syntax, it might look a bit cryptic. And I have seen some people complained that it is very verbose. On the contrary, I would make a bold claim that F# beats most other languages when it comes to conciseness. You don’t believe me? see it your self (make sure you check all implementations)
A couple of toy projects of mine
I have developed commercial applications with F#, but as public stuff here are a couple of projects I have built. One is a full blazor/web assembly project:
And the actual app for the 3D bin packing problem, in which items of different volumes must be packed into a finite number of bins or containers each of a fixed given volume in a way that minimizes the number of bins used.
Trying and learning F# really requires you to dismiss your prejudices and be patient. But in the end, once you master the functional paradigm, it makes you sleep better as a developer.