Thursday, 3 November 2011

Why F# needs Mono (and really should be a JVM language)

When people think about .NET development, they think of C#. Sure there are other languages (VB, ASP.NET etc) but .NET and C# are very tightly linked (just drop an .NET assembly in reflector for technical proof). If you're writing a new Windows application (and it's not a high performant game), chances are you are reading WPF books right now.

One of the promises of .NET when it was released was "the great language independent" runtime, making all these languages interoperate in joyful blizz. Technically this still holds, but in practice it's all about C#.

F# is still considered a new .NET language, but the fact is that it's been around since 2007. Let me tell you, it's an absolute gem of a language, and it's a fully supported in Visual Studio 2010. F# is however not .NET the same way C# is. Drawing from it's OCaml roots, it doesn't feels like typical Microsoft technology (it's just too darn good :) It seems more at home in the open source world (the F# compiler is in fact open source).

In the recent Microsoft 2011 build conference, where Windows8, WinRT, future of Silverlight, new Visual Studio etc was announced. F# wasn't mentioned in the headlining presentations. How much mind-share does F# have internally at Microsoft?

The approach taken by the F# team is to educate the C# crowd, and win them over on technical excellence. It's a valid strategy, but it's going to be a very long process. Force feeding a new language and a new programming paradigm to the OO crowd is a very hard sell. What needs to happen in the .NET community for F# to gain ground is pull rather than push. A couple of high profile Microsoft apps showing off F# to the world (just see what Rails did for Ruby) and get the C#-ers' attention.

.NET being Microsoft technology, it's Windows only. Microsoft have opened the runtime standard, but it's a mine field of patents, and Microsoft has an army of lawyers. If you're a non-windows user your only hope is Mono, a open-source .NET runtime and C# compiler with a limp. In my experience, it's not ready for running production code. Some of Mono's core technologies, like it's garbage collector is not up to scratch. I can still easily get the runtime to crash using the experimental "generational gc". Some really core .NET libraries is missing, like WPF, and it doesn't support tail call elimination.

F#'s creator Dom Syme is flirting heavily with Mono, and he understands the importance of getting the universities and hobbyists on board. There is no way they are going to fork out for a Windows and Visual Studio license. F# is included in the standard Mono release, but it's still missing from the MonoDevelop IDE. Tomas Petricek has made a F# plugin for MonoDevelop, but not yet officially included in MonoDevelop, and doesn't work for version 2.8. A big part of the potential F# community is in the open source world, so F# needs Mono. Too bad Mono isn't good enough.

F# is perceived more of a "server room" language, leaving the UI code for C#. Technically, this is false, but that is a bias that will be near impossible to break. Server rooms are the domain of *UX, thus once again F# needs Mono.

So, F# have a tough battle of survival against C# on Windows and a weak story in the open source world. F# sorely needs a good open runtime, it deserves it. Mono's main contributing company Xamarin seems to have it's focus elsewhere (iPhone apps written in C#) instead of fixing the basics. It's worth noting that there are other promising projects on the horizon however, vmkit might come along and save the day? Unfortunately it's going to be a long wait.

I've thought many times how awesome F# would be if it targeted the JVM. Scala would be completely redundant and F# would have a much bigger and more eager user base. There is a F#-shaped hole in the JVM language space, and given it's open source heritage, I am sure it would be big hit. The server-room developers are now starting to use Scala and Clojure, just imagine what they could do with active patterns and asynchronous workflows! The JVM world needs solid ML language, there have been some valiant attempts, but none of them have taken off.

Mr Syme; just think how much easier this would all be if you were in the JVM camp? :-)

Ps. Here's a workshop presentation by Richard Minerich showing F# in Mono and MonoDevelop.

Update: After talking to some people in the F# / Mono community, my lacklustre attitude of Mono has slightly changed. The TCO problems is fixed, which I can verify. And even if we all agree that the Mono + F# tooling situation is bad, the runtime seems to in a better shape than I feared, and are indeed used in production. I stand by my absolute conviction that F#'s fate is tightly linked to Mono's, and thus deserves the full attention from the F# community.


  1. Good article, I generally agree, but a few comments:
    First, ASP.NET is not a language, it's a framework.
    You mention "in practice it's all about C#", but I've been interoperating C#, VB.NET, Boo for a few years now (and more recently F#), it's not just a technicality, it's really practical. And all of this server-side, on Windows.
    Also, F# would never obsolete Scala. I love F#, but Scala is a much more powerful language. It has a much richer type system, take a look at Scalaz for example. If anything, it's the other way around: Scala would obsolete F#.

  2. I'd like to know more about why Mono is not ready for production code. Sure, Xamarin is probably focusing more on where they make money, but still. The last comment in the linked article reports that Tail-Call optimization was fixed in Mono over a year ago. It would be awfully nice if MonoDevelop 2.8 supported F#.

  3. @Mauricio

    Thanks for you input, you are quite right about ASP.NET. I am not arguing wether .NET works are multi language runtime or not, I truly does.

    The point I was trying to make was (in my experience) there is a big '==' in peoples perception of .NET and C#. I heard them used interchangeably, this is true in the Mono community as well. Thus, it's hard for a new language to gain mind share.

    My remark about Scala in very much my humble opinion. I have spent some time with Scala (and will post my Scheme interpreter written in Scala soon), and I do like it. It's one of my 2 favourite languages on the JVM :)

  4. @Robert You are quite correct about Mono and TCO. My info was updated, I've just tried this on 2.10.6 and it does indeed work. Thanks for pointing this out.

    As for you question why I say Mono is not ready, it's just my humble opinion. I wouldn't put any production code on a mono runtime if I was in the position to make such a decision. There seems to be quite a lot of companies how has come to a different conclusion however;

  5. man I think as you...I've developed with clojure and now I'm trying f# and I'm absolutely in love...I feel than f# for the microsoft comunity is only a toy...even in f# books they refer at f# like a language interesting to learn for know the functional future for c#...

    I like .NET and I've finding many uses..and I feel than mono isn't so bad..actually is pretty good...but can use f# in the jvm would be the holly sh%"t..

    I don't know if this would be possible...actually the clr is many step further than the jvm...maybe you than has much more experience would clarify me if this is possible..(I don't know much about jvm generics and tail call)

    some interesting about f is than it has many books (and they are pretty goods)...the visual studio integration is well but I don't know why..if fsharp is a first class citizen inside .net...why isn't supported in the latest monodevelop version when ironpython is fully supported..

    I hope u can understand my poor english..I'm italian...good luck and we hope than fsharp has a wonderful future (and clojure too!!)

  6. @coco Re: porting the F# to the JVM. Well, it's possible of course, but not without challenges :) I think the biggest problem is going to be replicating the .NET interop with JVM interop. F# is hard-wired into .NET and a lot of it's design/features is based on that assumption of .NET as a target.

    While the compiler is boot-strapped (written in F#) as could be ported, all F# programs (including the compiler!) needs to change from using System.* to java.*. That's a radical change. If you look at other languages with this approach (Clojure etc) you'll notice that JVM/CLR/JS programs are quite different.

    That said, I think it's a worthwhile project, especially if you are considering the future of F#. Imagine F# development being lead by an independent foundation (such as eclipse) instead of a profit making organization (M$). I recon high on that foundations agenda would be to get F# on more platforms and thereby driving up the usage / mind-share. Another important goal would be to create a web framework like Rail/Lift).

    Being totally tied into the Microsoft/Visual Stuio sphere, F# risks not reaching a cricital mass and thus fading away.

  7. I think the F# compiler relies heavily for its type inference on the generics as implemented on the CLR (said generics were implemented by Don Syme itself, the creator of F#...). CLR generic types remain generic once compiled, while Java generics use type erasure (mainly for compatibility with older JVM's if I recall correctly). This could prove very challenging if someone would want to port F# to the JVM.
    On the other hand, scala managed to have a complex type system language compiling on the JVM, so not all hope is lost.


Note: only a member of this blog may post a comment.