
Ask HN: How viable is F# on Mono for real-life web apps? - herokusaki
The reason I&#x27;m asking is that F# appeals a lot to me (more so than Scala, the language that seems the closest competitor) but I have not found success stories from companies running their C# or F#  web apps   on Mono&#x2F;Linux.<p>As a separate but related question I would like to ask what tools you&#x27;d recommend for developing in F#  on Linux or OS X.
======
endeavour
It's viable. Mono is very good these days. It's pretty rare that you find .NET
libraries that are incompatible. I still use Visual Studio as an IDE but
deploying to Linux is straightforward.

Your options are (realistically): Websharper - full web stack, transparent
RPC. Hard to interop with native JS libraries like angular though.

Funscript - F# to JS compiler, more minimalist approach.

F# server side (REST api in Nancy/Fanciful/WebAPI) teamed with javascript
front-end. Also well worth checking out Livescript, syntax is very similar to
F# but dynamically typed.

See also: A relevant blog article I posted:
[http://thecodedecanter.wordpress.com/2013/06/22/hosting-
webs...](http://thecodedecanter.wordpress.com/2013/06/22/hosting-
websharperasp-net-apps-on-linux-with-mono-nginx/)

My consultancy (just in case):
[http://www.perfectshuffle.co.uk](http://www.perfectshuffle.co.uk)

Always up for a chat if you have some ideas :) Shoot me an email through
website above or PM me.

~~~
giulianob
If you're using Mono for web hosting then don't use Mono's FastCGI
implementation. It's incredibly slow from what I've seen. Instead, use
something like evhttp-sharp which has a wrapper for Nancy. Just to give you an
idea look at nancy using evhttp ("nancy-libevent2" in the benchmark) vs
FastCgi ("nancy" in the benchmark) at
[http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...](http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=json&s=2&l=2)

I've tried to contact the folks who are maintaining FastCgi on Mono but the
email I sent last week bounced. When you use evhttp though, (at least with C#)
there's not a huge performance difference than when using it in Windows.

~~~
candl
Awesome, I wasn't aware of evhttp-sharp. On first glance it seems not to
provide any Owin middleware compatibility, but it should be easy to do a small
server factory that plays with Microsoft.Owin.Hosting and get that out of the
box. I've also found
[https://github.com/Bobris/Nowin](https://github.com/Bobris/Nowin) a while ago
- very fast on Windows, but I can't get it to work on Mono 3.4 on linux, locks
on the first request.

~~~
giulianob
If you do make it OWIN compatible or a FastCGI wrapper for libevent that would
be awesome. Right now, you need to basically have nginx proxy all the requests
to evhttp which probably adds a little bit of overhead over doing it through
FastCGI directly.

Edit: Actually from what I've seen, Mono uses epoll/kqueue for async IO which
is what libevent uses as well. I think the problem might not be so much that
libevent is faster than what Mono can do in plain C# but rather that the
FastCGI implementation has some bottlenecks or is not using the most
performant APIs available. I haven't had time to profile it though.

------
kevingadd
One big thing to watch out for is GC differences. Now that Mono has sgen the
gap between it and MS's CLR isn't so huge, but you will definitely want to do
some memory and CPU profiling direct on the webserver to spot any issues.

In my case when rolling out the JSIL compiler (mostly C#, but using some F#
applications as test cases etc) certain BCL containers had dramatically
different GC pressure profiles, and GCs would trigger at different rates and
with different costs. F# tends to generate a lot of GC pressure so you want to
be proactive about this.

Side-by-side, though, sgen works pretty well. I've used it extensively and it
does the job.

------
orlandpm
At Tachyus (tachyus.com), we are using 100% F# to build the back end of our
platform. Getting from zero to our first product deployment in three months,
we've proven that F# is a great language for real world web projects --
especially when iteration speed and application correctness are both
indispensable. Visual Studio and Windows Azure have actually been a huge part
of the leverage we've gotten from choosing F#, as we can build, debug, deploy,
and manage deployments directly from the IDE. With an Azure trial account
created, you can literally get your first F# site up in minutes.

Unfortunately, I can't answer your question about Mono just yet. We are
exploring the practicality of Mono (for mobile development in F#), and while I
am optimistic, I can't speak to the reliability of the platform. So my answer
(a complete cop-out) is to try out Visual Studio unless you are completely
tethered to Linux/Mac.

------
sitharus
With the new sgen GC it's viable. The old Bohem-based GC was pretty terrible
with F# as it allocates a huge number of transient objects.

As for tools, beyond frameworks Xamarin Studio has a good-enough F#
environment. There's also an emacs major mode.

------
DanielBMarkham
I'd be curious as to what exactly you mean by "success stories". If you mean
something along the lines of "is it easy to develop, has a robust environment,
and doesn't present any hard problems" then I think there's a lot of companies
out there. If you mean something like "will it help your company produce
something people want"? Then you're asking the wrong question. Tech _very
rarely_ determines product-market fit, at least not to the degree that we
developers think it does.

I've been using F#/Mono for my small apps for some time now. For an example,
my personal news aggregation site,
[http://newspaper23.com](http://newspaper23.com), is running all the time,
going out and finding headlines and presenting them to me in plain text. Been
meaning to add a text stripper to the mix so I don't have to see any ads or
participate in any sticky website nonsense at all; just haven't had time to
code it yet.

The nice thing for me, especially for this app, is that I can use F# in a
purely functional manner to create little unix-like programs that do a little
bit of work at a time. Then I string them together with chron and, instead of
the old client-server web model, I have something more resembling a data
_pipeline_. I can monitor flow across the pipeline, distribute parts of it to
other machines (scale out) if necessary, and so on. All without having to re-
code anything. The entire thing serves up a static web page, which can also be
tweaked: served in-place, over a CDN, emailed to a user, etc. Did I mention
the "no recoding" part?

As a former .NET guy, I'm happy enough with F#/mono that I can't imagine going
back to full-bore .NET no matter what the problem domain. The toolset is way
too heavy, the culture is awash in folks marketing to developers instead of
helping them build stuff people want, and so on. It was a great ride, but
F#/mono is where I get off.

Having said that, I still use the VS IDE to develop, since you can develop in
windows and then FTP the code over. That's pretty cool. I've tried and used
MonoDevelop. I guess it's okay. I've also done a bit with just straight-out
command-line compiling. After all, it's not like you need a huge codebase full
of hundreds of files. Or if you do, you're doing something wrong :) An 8 or
10-file F# program is a monster -- and probably means you're trying to do too
much at once.

------
granicz
In the past few weeks, we have been porting WebSharper IDE support (project
templates, build, deploy and run) to MonoDevelop and Xamarin Studio, and apart
from a couple smaller glitches this work is now done, and you should be seeing
WebSharper for MD and XS released in the coming days. (Until then, you can
manually invoke WebSharper if you are careful with the command line options
and don't mind scripting the process.)

We have not yet succeeded, though, in making CloudSharper Local run on mono
due to some unimplemented methods in the mono stack. Once these are addressed,
you can also develop mono/Linux F# web apps in CloudSharper, and should
hopefully find that experience a lot less daunting than using the conventional
IDEs.

~~~
riles01
Very excited to learn of the templates being made accessible in Xamarin
Studio! I can't wait!

------
DenisM
Have you done the math for running it on windows rather than mono? Depending
on your projected workload, it maybe fairly cheap.

------
autodidakto
I played with Xamarin Studio + F# + OS X about a year or two ago. Right away I
noticed that F# is a second class citizen in Xamarin. Weird bugs, weird
warnings, unfinished parts, hard to find help online and in IRC channel. And
since it's a smaller language, there are 1/100th the number of
tutorials/resources at much lower quality. Anyone who wanted to run my app on
Linux or Mac had to deal with Mono 2 vs Mono 3. Despite spending a lot of
time, I never figured out how to compile a windows binary on Mac or a Mac
binary on Visual Studio (or how to have a project folder that works both in
Xamarin and Visual studio without both git problems and linking problems).
Starting a C# project is a pleasant experience, starting a F# required
searching for add-ons and manual configuring (both in Xam and VS). I couldn't
even run the iOS sample app without paying hundreds of dollars for the full
version because the iOS libraries made the binary (of the one page sample app)
to big for the trial version. Response in IRC was "yeah, we know. Oh well".

A real shame. I'd love to dedicate myself to an open source functional
language with a GUI toolkit that runs all platforms, desktop and mobile.

~~~
endeavour
I think unfortunately this is true. But it's a chicken and egg problem. F#
won't get more attention unless more people use it.

JVM developers seem to be much more open-minded than .NET developers for
whatever reason. As someone who thinks F# is a much nicer language than Scala
(the best JVM statically-typed, functional language) it's quite frustrating.

~~~
olmo
The reason is that C# is a better language than Java, so there is less pain
and less reasons to move away to a newer language.

------
platz
Mark Seemann made a nice tutorial on Pluralsight, which shows how to build an
F# web app.

The demo isn't using Mono, but I thought it's still relevant if you want to
get a feel for what an F# web app might look like.

[http://pluralsight.com/training/courses/TableOfContents?cour...](http://pluralsight.com/training/courses/TableOfContents?courseName=functional-
architecture-fsharp)

------
segphault
Mono's compatibility is quite good across the board, but there aren't a ton of
contributors focused on backend stuff. There are gaps in Mono's library stack
that are problematic for web applications (e.g. no System.Net.WebSockets last
time I checked) but it's not really all that bad.

Microsoft has started making a lot more of the ASP.NET stack open source
(EntityFramework, Razor, etc), which I think will help a lot going forward.
The real problem is that the ASP.NET happy path is somewhat coupled with IIS
and (to a lesser extent) with MS SQL Server. It can be hard to get portability
out of the box in some cases, but it depends a lot on what you are trying to
do.

------
owlmonkey
We have a product that has a C# web app deployed via mono on a linux box
commercially shipping for four years. What I found was that with mono 2.10.6
it was fine as long as it was not loaded heavily, but under stress it would
have stability issues. The socket layer was rewritten since then however and
I've had less issues with 2.10.8/9 but still fails under heavy load. More
fixes have gone into mono 3. My sense is that it's getting better but not
nearly as battle tested compared to JVM-based network stacks. So if I was
coding a large scale web service I'd consider Scala first.

~~~
profquail
Have you tried using one of the newer versions of Mono (3.2.x)? The SGen GC is
much better than the old Boehm-style GC, and SGen itself has improved by leaps
and bounds over the past year.

~~~
owlmonkey
Haven't tested on 3.2.x yet but the GC was never the issue for our stress
tests. Bugs in the socket layers were killing us. Better under 2.10.9 but
still not completely resolved.

------
runT1ME
are there features that F# has that scala is missing (aside from reified
generics)? Because there are at least a few critical features scala has that
F# is missing that influenced my decision on preferred language.

~~~
endeavour
The type inference is much better in F#, the syntax is much terser,
discriminated unions are much cleaner than case classes.

Also .NET/Mono benefit from a VM with much better performance characteristics
(tail calls, value types).

Scala has its own set of benefits too (incredibly powerful type system,
Scalaz, bigger community).

F# is primarily a functional language with some OOP bits tacked on. Scala is
the opposite.

~~~
Dewie
> Scala has its own set of benefits too (incredibly powerful type system,
> Scalaz, bigger community).

What's the general consensus on scalaz nowadays? Some people seem to think
that it is evil itself (or rather the style that it promotes). I'm an outsider
so I wouldn't know.

~~~
runT1ME
I consider it more important than the standard library. I can't live without
it. In version 7 (current), they moved away from using symbolic method names,
and now they require 'regular' names, and symbolic method names are optional
syntactic sugar. That was by far the most common complaint.

------
frozenport
Don't do it because other people will have trouble with your code. Consider a
job posting for F# vs one of the more commonly used languages.

~~~
JackMorgan
I think anyone who wants to use an unpopular and more powerful language
(especially in Enterprise-land) should understand the tradeoff they give up
for that power: you'll have a harder time finding a lot of "B level"
developers. You'll have to either hire new grads and train them, or be content
with a smaller pool of "A level" candidates who all care enough about their
profession to learn something solely for their own betterment and who aren't
afraid to learn something outside C#/Java. And who will likely all cost more.

If you need to fill a 100 head-count office, with likely overseas handoffs,
perhaps a less powerful language would be better.

It's all about context.

~~~
frozenport
As the author pointed out, F# seem small.

If you want functional programming choose one that you can find devs for! Is
F# worth the trouble, is it any way better then more accessible FP langs? Lets
be practical here.

In my opinion, any 'A level' candidate that knows F# probably works for MS.

~~~
JackMorgan
Ah, I was thinking you were saying "don't use F#, just use C#/VB.NET". Which
has a valid use case, to be sure, but was sort of against the spirit of the
OP's question.

If I was starting greenfield, with no SLA's about a particular runtime, I
think F# would still be pretty high on my list, assuming Mono support was
there. It's basically OCaml + huge libraries and a kicking VM. I think my next
go-to for a bigger team, heavy typed language would be probably clojure.typed,
followed by Haskell or OCaml, due to a combination of simplicity, power of
language and typing, and my current comfort with each.

------
srean
TL;DR version: Felix is a very F#'ish language that might pique your interest.
Felix is to C++ what F# is to C#

Full disclosure, this has been said of me recently: > AFAICT you mention Felix
whenever OCaml comes up, generally saying more or less the exact same thing
each time

So you might know about Felix already, if not read on. I dont want to sound
repetitive if it is not welcome please let me know if I am overdoing this, so
far the reception has been warm in other threads. [Said too soon I guess,
downvotes are ok, would appreciate if they come with some feedback as well]

Let me point you towards my comment
[https://news.ycombinator.com/item?id=7416692](https://news.ycombinator.com/item?id=7416692)
that has more details

Felix's website is running on the web server that comes with its standard
library. It is well suited for webapps because of its strong support for
efficient asynchronous I/O, futures and coroutines (which I believe has been
maintained for 10+ years and used in ATM networking applications). These help
in avoiding callback heavy code. Hooks into JS is currently missing, but if
you are adventurous, interfacing it with V8 should not be difficult because
interfacing with C++ has been Felix's design goal from the very beginning
(analogous to how F# and C# are related). In fact if you express enough
interest, the language designer, John Skaller, might be up for it himself (You
can catch him on LTU or the Felix mailing list). As of now it has two
backends, GCC and Clang. John has some interest in a Javascript backend as
well in case there is sufficient demand for it. If F# is something that
interests you, and the performance of F# on the mono runtime worries you a
bit, Felix might be worth poking around, especially if you are an early
adopter.

~~~
jnbiche
You're overdoing it. I"m sure Felix is a wonderful language, but spamming
every FP-related post with the same comment about Felix is not a great way to
introduce people to the language.

You should probably focus on contributing on-topic comments to this post in
question (in this case, F# on Mono), and then leaving a _very brief_ mention
of Felix. People will check it out if they're interested.

~~~
srean
Noted and upvoted for leaving feedback. Although spamming _every_ FP thread is
bit of an overstatement, I think.

My experience with mono and F# has been rather underwhelming as discussed in
the F# thread a couple of days back, so I am eager to try it out with sgen,
but web applications arent my forte. I think F# can make a fine language for
scientific and numerical applications as well, in particular, I think
recursive linear algebraic algorithms implemented using algebraic data types
would fill a rather unpopulated sweet spot.

