F# + Mono: first-class citizen, or read-headed stepchild?

[spiffytech]

Hello! I'm considering switching my Python project over to F#, with development and deployment on Linux. I see a number of references to using Mono with F#, but I'm struggling to tell whether it's a good idea, or just an instance of an alternate deployment target that doesn't get nearly as much community love as the defacto runtime.

Is F# + Mono more like "it's a thing you can do if you really want to, but not a lot of people do, and nobody's going to call it their favorite programming experience",

or like "it's very common, and a great experience, and isn't majorly lacking compared to using Windows + Visual Studio"?

Thanks!

[Adam Granicz]

Switching to mono might just be the worst thing you can bring upon yourself if you are working with more involved scenarios, but it can work for ordinary simple F# projects.  We had to rewrite quite a bit of F# code to enable it to run on mono working around functions that didn't have a mono implementation, and had massive problems while trying to implant custom build logic into xbuild (which we ended up moving to an F# build task eventually) finding out that even basic target resolution works differently from msbuild.

In short, build support is barely workable, library coverage is decent but lacking in various places (and some the mono team has no intention to support), and speed of execution is poor as reported by many.  Xamarin is concentrating on their premium offering nowadays, and it looks like they are slowing down attending to core mono issues.

Nevertheless, it's worth a try.  We are relying on it in some of our projects (CloudSharper, most notably) and while it gives us many headaches it does help to reach a new audience.

--
--
To post, send email to fsharp-o...@googlegroups.com
To unsubscribe, send email to
fsharp-opensou...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fsharp-opensource
---
You received this message because you are subscribed to the Google Groups "F# Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fsharp-opensou...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Adam Granicz, IntelliFactory
www.intellifactory.com

[spiffytech]

Well, that's sad news. Can you please elaborate on what is simple vs involved for an F# project? I'm working on the HTTP-facing server component for a real-time strategy game, and hoped I could use F#'s JavaScript generation ability to share object definitions and processing code between the client and server. My project will have a number of components (various portions of AI, physics, etc.) that will have to be split up into different sections of my codebase and get compiled together. Does this sound like a very involved F# project?

What are some of the more glaring missing libraries / runtime deficiencies the Mono team / Xamarin aren't attending to? (Besides the build system issues you mentioned). Are they things that one is most likely to encounter only when solving select technical challenges, or things that are easy to hit no matter what you're working on?

[Tomas Petricek (Info)]

Hi,

Sorry, but I think Adam’s perspective here is not entirely neutral (he expressed his dislike for Mono and Xamarin for non-technical reasons a couple of times and his company is selling a product that competes with Xamarin tools in some ways). As Adam didn’t include any disclaimer along these lines, I just wanted to add that myself to clarify.

 

I’m not using Mono as my primary F# development platform, but I know that a number of people happily do that (and hopefully they’ll report their experience to balance the message!)

 

One thing I’m pretty sure though is that pretty much all of the major F# open-source projects are using Travis CI as a continuous integration server on Mono (and so they all *build*, *run* and pass all the *tests* on Mono).  This includes the F# compiler, core libraries (https://github.com/fsharp), many of the F# projects (https://github.com/fsprojects) and also things like our data-science toolkit (https://github.com/BlueMountainCapital/Deedle). So I’m pretty sure that the reality is different, but as I said, I have only limited experience myself.

 

Thanks,

Tomas

 

PS: I don’t want to start a flame-war so I’m not going to reply to further emails in this thread (even though I’m expecting a long list of objections from Adam in reply).

[Adam Granicz]

No long list of objections from me, I gave up responding to trolling a long time ago, fortunately.  But since Tomas mentioned our products, the fruits of years of hard work from dozens of people on our team over the last few years, let me just point out that Tomas is a regular contributor to several projects that compete with our more established open source tools, for no apparent reason.  So as you can tell from his email, there is somewhat of a disagreement between us two - but don't let that derail your attention from the mono issues at hand.

So.  In my report above, I listed concerns about mono's 1) xbuild, 2) .NET API coverage, and 3) execution speed.  Here is a handful of issues our colleague Anton filed about xbuild:

https://bugzilla.xamarin.com/show_bug.cgi?id=15325

https://bugzilla.xamarin.com/show_bug.cgi?id=18761

https://bugzilla.xamarin.com/show_bug.cgi?id=19249

Note that none of these have responses from the mono team.  Regarding .NET API coverage issues, I recall having to work around missing streaming methods in System.IO, inter-process communication (notably, via anonymous pipes - see issue #19055 - where Miguel himself noted that there were no plans to support/add the missing method), and the build API, among others.  For me, these qualify as "more involved" F# projects.  An example is CloudSharper itself.

On 3) - I have yet to find anyone who thought that mono execution speed was on par with its Windows counterpart.  Just as you can find happy people using mono+F#, you can find at least as many who are dealing with constant performance issues.  For what we do, performance is not a showstopper, and I imagine this is the same for the satisfied users as well.

I am happy to share more of our experience with mono and I don't mind if anyone starts a discussion or "flame war" with valid concerns.  My mail was not a statement on mono, which we rely on as I said in several of our projects, and which I believe is good for the F# ecosystem.  What I eluded to and what I voiced before as well on other forums, is Xamarin's clear change in direction to use the mono base to funnel people into their premium offering.

Cheers,

Adam.

[Robin Neatherway]

Hi,

I have been using F# on Linux for the past four years for some heavy algorithmic work. Our team develops on both Windows and Linux, and we typically run our code on Linux servers. Although there are some rough edges, the situation has improved enormously over this time. The quality of support for MSBuild is one example, that now works well, but was very difficult a few years ago. Probably the most troublesome aspect is having to do a lot of compilation of packages from source yourself, as Mono in many distributions is incredibly out of date. Debian testing does now have a fairly recent Mono and F# 3.0 though. I think that Monodevelop 5 is a solid alternative to Visual Studio as well by this point.

Deploying an application is fairly easy, it doesn't require the user to have F#, as you can just bundle FSharp.Core with the application.

Performance-wise, for our CPU-bound loads, we didn't see any significant different between Windows and Linux. The only thing is that it is simple to use ngen on Windows to avoid JIT startup overhead and this is not straightforward with Mono.

To be honest, I think calling Mono + F# a "first-class citizen" would be going a bit far, but it is fairly solid in my experience. When it has come to bugs in the Mono runtime that affect F# in the past, I found that Xamarin dealt with them quickly. I am optimistic.

Hope that helps,

Robin

[Kevin Ransom (MSFT)]

Disclaimer:  I work on the Visual F# Tools team for Microsoft.  What follows is just my opinion.

F# on Linux has a very active development community, with lots of developers doing lots of good work.  For example the send to FSI feature appeared on Xamarin before we added it to Visual F# Tools.  Xamarin has a first class mobile cross platform story, that F# fits into pretty well.

I think anyone can choose Windows or Linux depending on their personal preferences and target platform requirements, regardless of the choice of tools a new developer will find a supportive and enthusiastic community of developers eager to help improve their skills. 

The coolest thing to my mind is that you will be able to directly contribute to one of the numerous F# open source projects aimed at improving the development experience of F# developers on all of the supported platforms.

Get started with F# choose whichever environment is easiest for you to start with, have fun and make good use of the F# Community, get involved with improving the toolsets that you use and have a good time.

Kevin Ransom

http://visualfsharp.CodePlex.com

[don...@fastmail.fm]

Hi @spiffytech,

 

A few things to add 

 

• Relative to 12 months ago, F# + Linux/OSX are vastly better than they were.  I now confidently say that the combination is solid for many practical purposes. Relative to 24 months, we're talking light years of difference. The rate of progress is high. I believe this will continue.
  

 

• F# + Linux/OSX is getting a lot of love from the community at the moment.  As much as Intellifactory's experiences haven't been 100% positive, I'm really impressed that they are taking a sophisticated and powerful set of F# web and/or server programming tools onto Mono. I think this is a sign of the F# world's engagement with Linux/OSX and improvements in the core of the system.  There's some heat to be sure, but there's engagement too. 
  

 

• There is a lot of other community engagement with Linux/OSX. For example, many F# community-engineered components (e.g. the F# open edition compiler, the FSharp.Compiler.Services and FSharp.Data) use a regular Travis build/test on Linux or OSX.  There's also tooling work going on - Emacs support, MonoDevelop bindings, Xamarin Studio as an IDE, by people regularly using F# on these systems.
  

 

• As Adam explained, Intellifactory are pushing the limits on Mono's xbuild tool (the cross-platform build tool that lets you build the same project file formats used by Visual Studio). On the whole xbuild seems to work well for project build files authored from the Mono Develop, Xamarin Studio and Visual Studio IDEs, but can have more trouble with project files written by hand or cross-platform compatibility in the build targets for specific frameworks. If you push the limits with xbuild, you may need to contribute fixes to problems.
  

 

• From what I see, Xamarin are good contributors to Mono, but there are other contributors too. Xamarin rely on Mono for Xamarin Studio on OSX - this is a non-trivial IDE system that is really driving improvements in Mono. The improvements to GC in Mono 3.2.x have been significant.  Xamarin also use modified versions of the Mono compilation stack for their Android and iOS tooling. However my understanding is that Xamarin see their contributions to Mono as a means to an end, rather than a business in itself.
  
  
• There are many C# or F# libraries which work cross-platform - e.g. Math.NET is one example I like to point to. 
  

 

• Some current areas that need work are around Portable Class Libraries (mostly the problems are with making PCL libraries fully portable across all of MonoDevelop, Xamarin Studio and Visual Studio). 
  

 

Overall, I'm very optimistic about F#+Mono/Linux/OSX.  I'm also realistic that there can be hard work in making cross-platform tooling, or making major pieces of code+build truly cross-platform.

 

Cheers,

Don

 

p.s. disclaimer: these are my opinions, not those of my employer

[don...@fastmail.fm]

 

One final exhortation: even if you're working on 100% Windows you can still easily build/test your open source code on Linux/OSX.  

 

Simply set up a Travis build/test of your project (or equivalent CI). It is free and easy - basically you just place a .travis.yml in the root of your GitHub project, e.g.

 

    https://github.com/fsharp/FSharp.Data/blob/master/.travis.yml

 

Once you sign up with Travis and register your GitHub project (a couple of clicks), then all commits and PRs to your repo will be automatically built and tested using the configuration and scripts specified.

 

In this way, you don't actually ever need to install or use a Linux or OSX machine - you can stay 100% on Windows and yet still get high confidence your code builds and passes tests across multiple platforms.  It's been great to see this working for FSharp.Data and other projects.

 

Cheers

Don

 

p.s. again just my opinions and not those of my employer

[Dmitry Morozov]

The absence of proper PCL for F# in Xamarin is real issue for us in Tachyus.
We cannot share business logic between F# Azure back-end and mobile front-end.
At also a blocker for cross platform UI project I'm working on https://github.com/fsprojects/Tamarin.
I wish it will be fixed ASAP.

[Kevin Ransom]

A solution is on the way.

Sent from my Windows Phone

---

From: Dmitry Morozov
Sent: ‎6/‎8/‎2014 4:51 PM
To: fsharp-o...@googlegroups.com

Subject: Re: F# + Mono: first-class citizen, or read-headed stepchild?

[spiffytech]

Wow, thanks for all the responses! I like seeing all the positive experiences. F# sounds like a really neat language, and I'm glad to hear the Linux story is good and getting better! I look forward to sinking my teeth into it!

[Veikko Eeva]

Man, that was a quick response! Maybe I shouldn't be suprised if the solution is on the way in the bus and hits the servers when the phone gets synced at the office. :-P

[Dave Thomas]

I can't speak for linux but the osx platform is pretty good for F# development, I gave up with my frustrations of Windows years ago and haven't looked back.  

You can use the Fully open source MonoDevelop for F# development or use Xamarin Studio if you want to target mobile platforms like Android or iOS.

Dave.

[Paul Blair]

I've just spent a few days writing a small application in F# on OS X with Xamarin Studio. Overall it was a good experience. Xamarin Studio isn't IntelliJ IDEA, but the basics are solid and it's quite usable. Every now and then you run into minor weirdnesses (e.g., for some reason every time I close my solution and re-open it the last project gets dropped from the solution) but they haven't been the kind of thing that cost a lot of time or effort to work around.

What cost me the most time was actually working with SQLite and the SQLProvider. The main issue was getting FSharp.Data.SqlProvider to see the System.Data.SQLite.dll . The fact that you're on Mono makes this kind of problem harder to research; you don't know if it's a Mono thing, a Xamarin Studio thing, or an issue with setting up the type provider. For example, System.Data.SQLite ships with dlls for specific processor architectures, and it's somewhat unclear whether you can use the dll in the NuGet package with Mono. I wound up downloading the source and compiling the dll for Mono, which turned out to be straightforward. The reason I'm using this as an example is that when you run into problems like this, researching them can be difficult and adding an unusual platform does make it harder.

There are certain areas where you can know ahead of time that you won't be able to run Windows code on Mono. For example, I recently came across a code sample I wanted to try in F# Interactive, but which wouldn't compile owing to a reference to WPF, which Mono doesn't support. In general, though, my impression is that unless you're trying to do things that are very Windows-specific or hardware-specific, using third-party libraries on Mono is pretty straightforward.

[Dave Thomas]

What happens a lot is nuget packages are not xplat or even properly configured for portable libraries.  If you get issues make sure to log them.  

--

--
To post, send email to fsharp-o...@googlegroups.com
To unsubscribe, send email to
fsharp-opensou...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fsharp-opensource
---

You received this message because you are subscribed to a topic in the Google Groups "F# Discussions" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fsharp-opensource/AX-Mwwe0fGI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fsharp-opensou...@googlegroups.com.