We're hiring!

We're actively seeking designers and developers for all three of our locations.

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.
 

Al Scott (14 Posts)

Al Scott is a developer at Atomic Object in Detroit.

This entry was posted in Functional Programming and tagged , , , . Bookmark the permalink. Trackbacks are closed, but you can post a comment.

4 Comments

  1. KPX
    Posted June 11, 2014 at 1:55 pm

    There is a SQL database type provider for F# called SQLProvider.
    I haven’t test it on Mono so it may not work.
    http://fsprojects.github.io/SQLProvider/

    • Al Scott
      Posted June 17, 2014 at 2:39 pm

      I tried that provider, but I had trouble with the drivers it depends on. The SQlite driver (which is what I really wanted) isn’t available on Mono and I couldn’t get the postgres driver to work. After that I just gave up on it and moved onto other things. It looks like a great project though so hopefully in the future it will get better cross platform support.

  2. Paul Blair
    Posted June 17, 2014 at 2:33 pm

    I recently wrote a nice little application on OS X using Mono and Xamarin Studio – an IDE which builds off MonoDevelop. Xamarin Studio is available free of charge if you enter your email address. It installs Mono and F# out of the box, and I was off and running immediately with no errors. I used the F# SQLProvider with System.Data.SQLite (which I had to compile for Mono, but that turned out to be easy); it is still in alpha stages, though, so may not have everything you need.

    The management of projects, references and NuGet packages is straightforward in Xamarin Studio. I found code editing to be reasonably tolerable. It doesn’t have all the bells and whistles you’d get in an IDE like IntelliJ IDEA, but it does have, e.g., a Rename refactoring for F#. I found it to be extremely usable.

    • Al Scott
      Posted June 17, 2014 at 2:42 pm

      Xamarin studio was the IDE I initially tried. I kept getting errors with my F# projects though and couldn’t build them, which is what prompted me to switch to the source build of monodevelop. Maybe Xamarin has been fixed since I tried it though.

      I didn’t try to build System.Data.SQLite from source for Mono – that might be a good approach for me to try.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>