Live data from Hacker News

Ask HN: How viable is F# on Mono for real-life web apps?

news.ycombinator.com

31–38 of 38 posts

Re: Ask HN: How viable is F# on Mono for real-life web apps?

#31

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 o…

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.

Re: Ask HN: How viable is F# on Mono for real-life web apps?

#32
post #17

Earlier quoted context omitted.

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.

> 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.

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.

Re: Ask HN: How viable is F# on Mono for real-life web apps?

#33

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 o…

you can check user groups for developers, not too bad http://fsharp.org/groups/

Re: Ask HN: How viable is F# on Mono for real-life web apps?

#34

Earlier quoted context omitted.

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 o…

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.

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.

Re: Ask HN: How viable is F# on Mono for real-life web apps?

#36
This is a question I've had myself lately too. If I wanted typing, I think F# is my "first choice" language (assuming Mono support was good). So thanks for asking!

The other thing I'd investigate is the viability of clojure.typed, Haskell, or OCaml. They are very much like F# in a lot of ways, and maybe one of those would fill the need if you weren't comfortable with the state of F#.MONO?

Re: Ask HN: How viable is F# on Mono for real-life web apps?

#37

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 Na…

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...

Re: Ask HN: How viable is F# on Mono for real-life web apps?

#38

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 th…

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.
Post reply on HN