Ask HN: How viable is F# on Mono for real-life web apps?
16 comments
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...
My consultancy (just in case): 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.
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...
My consultancy (just in case): 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.
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...
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.
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.
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 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.
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.
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.
I second this. I worked on an ASP.NET MVC product that ran just fine on Mono. This was in the old 2.x days. While I didn't test FastCGI, the founder did, several times. He always told me mod_mono performed better.
I wonder what the TechEmpower benchmarks would look like if they used mod_mono instead of FastCGI.
I wonder what the TechEmpower benchmarks would look like if they used mod_mono instead of FastCGI.
Thanks, this is really useful!
Hey another follow up about FastCGI performance for those who are interested.
I asked on the mono dev list about FastCGI performance and it turns out there is a dev who wrote his own FastCGI implementation for Mono. It turns out that Mono uses .NET remoting to talk between the FastCGI process manager and the child processes and remoting is super slow. It would be interesting to see how it compares to evhttp but you can find the source here: https://github.com/xplicit/HyperFastCgi and his blog posts about profiling FastCGI here: http://forcedtoadmin.blogspot.com/2013/11/servicestack-perfo...
I asked on the mono dev list about FastCGI performance and it turns out there is a dev who wrote his own FastCGI implementation for Mono. It turns out that Mono uses .NET remoting to talk between the FastCGI process manager and the child processes and remoting is super slow. It would be interesting to see how it compares to evhttp but you can find the source here: https://github.com/xplicit/HyperFastCgi and his blog posts about profiling FastCGI here: http://forcedtoadmin.blogspot.com/2013/11/servicestack-perfo...
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.
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.
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.
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.
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.
As for tools, beyond frameworks Xamarin Studio has a good-enough F# environment. There's also an emacs major mode.
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, 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.
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, 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.
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.
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.
Very excited to learn of the templates being made accessible in Xamarin Studio! I can't wait!
Have you done the math for running it on windows rather than mono? Depending on your projected workload, it maybe fairly cheap.
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.
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.
You say it's been a year or two since you tried Xamarin Studio + F# -- I urge you to give it a try again, using up-to-date versions of both (and Mono too). There has been a significant amount of effort put forth by the F# community in the past year to improve the F# + Mono + Xamarin Studio stack; in fact, Xamarin hired one of the best F# developers/consultants in the community (@7sharp9) specifically to improve F# support in Mono and Xamarin Studio.
If you have any questions, or you try F# + XS + OSX again and still run into issues, post something to the fsharp-opensource list (https://groups.google.com/forum/#!forum/fsharp-opensource), or ask on StackOverflow.
If you have any questions, or you try F# + XS + OSX again and still run into issues, post something to the fsharp-opensource list (https://groups.google.com/forum/#!forum/fsharp-opensource), or ask on StackOverflow.
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.
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.
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.
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...
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...
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.
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.
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.
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.
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.
[deleted]
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
you can check user groups for developers, not too bad http://fsharp.org/groups/
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 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.
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 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.
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.
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.
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.
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.
As a separate but related question I would like to ask what tools you'd recommend for developing in F# on Linux or OS X.