Running F# Using Mono and Unix

Recently, I’ve been playing with the F# programming language in my free time. One barrier that I ran into was the fact that I don’t have a Windows machine, meaning I had to use the Mono runtime on my Macbook. This presented some challenges that I had to work through.

Why F#?

So, why was I playing with F# in the first place? I had been looking for a language to fix some frustrations that I had with my current toolset:

  1. Lack of static typing (JavaScript, Ruby)
  2. Lack of static typing that isn’t painfully repetitive (Java)
  3. First class support for common functional programming idioms – e.g. immutable by default, option types, pattern matching, etc. (All of the above)

I also wanted to take the opportunity to get some experience with the Microsoft/.NET ecosystem. Since the Microsoft stack is incredibly popular at many companies, including some of our clients, it seemed like a solid bit of knowledge to have. Also, I was excited about the possibility of using the Xamarin stack to create mobile apps with F#.

A Rocky Road

Getting my first F# project started, on my Macbook, was not a trivial affair. I had trouble with getting Mono and Xamarin Studio working correctly. I also had issues finding libraries that worked correctly on the Mono platform. The tooling for F# is also still a little bit rough outside of Visual Studio, which made managing my project tedious.

Getting Monodevelop Working

I had problems with the current prepackaged version of Xamarin Studio for OSX, which made working with F# very difficult. Specifically, I ran into this, which prevented me from building my F# projects and also messed up things like auto-complete in my editor. After trying some workarounds I found online, I eventually ended up grabbing the MonoDevelop source and building my own version to run.

Building my own MonoDevelop fixed the problems with building my project, but the build itself was very buggy — I had lots of crashing and UI issues. Fortunately, my favorite editor, Emacs, has a great plugin for F# including autocompletion and error highlighting (though I had to do some tweaking to get that working as well). This meant I could minimize my use of MonoDevelop and do all my code editing in Emacs.

Finding a Database Library

A second source of difficulty for me was finding open source libraries to leverage in my code. My specific problem was that I wanted to find a library that provided a simple high level API for interacting with a SQLite database. My experience, however, was a barrage of failures for reasons including:

  • Having to low-level of an API (Mono.Data.SQLite)
  • Not working with Mono (Microsoft.FSharp.Data.TypeProviders)
  • Not working on Mono on a non-windows OS (SQLite-net)
  • Not being designed to work with F# and having some clunky interactions as a result (Dapper, OrmLite)

After lots of trial and error, I ended up using ServiceStack’s OrmLite library, which satisfied my needs reasonably well.

Managing Code

Managing F# code and projects using MonoDevelop is a bit painful. The IDE was less than optimal in my experience, making editing slow. It was, however, the easiest way to do “IDE” tasks, such as managing library dependencies, adding source files, and building the project. The workflow I landed on was to keep MonoDevelop open for such tasks and to do all of my code editing with Emacs.

Nuget was another tool I had issues with. I could not get the command line client working and had to resort to using the MonoDevelop plugin. In the end, that ended up not being too bad though, since the MonoDevelop plugin actually worked pretty well and updated my project files with new dependencies automatically.

Final Thoughts

Overall, I would say that F# is definitely useable as a development platform off of Windows, but it is certainly not optimal. Anyone who wants to use the Mono/Unix/F# stack needs to be prepared for sub-optimal tooling and potential difficulties with 3rd-party libraries.

The future for F# only looks like it will get brighter with time. The language has a dedicated open source community and seems to be growing greatly in popularity. I think the near future may see F# break out as a general-purpose programming language. Microsoft’s recent open sourcing of the Roslyn C# compiler gives me hope that .Net has a future as a robust, multi-platform runtime like the JVM. If that is the case, I think F# has a particularly bright future. As it stands, the tooling and library support for F# on other platforms will only continue to improve.