Hacker News Reader

Comment by untothebreach | Hacker News Reader

Can someone give reasons why you would want to use this over, say, OCaml, when on a non-MS platform? My understanding is that the Mono runtime on *nix is significantly less {mature,performant,stable} that the Windows .Net runtime.

Are there any benefits besides the obvious 'write-once, run-anywhere' one?

EDIT: I just want to be clear that I don't have any negative opinion of F#, I am genuinely curious why someone would want to use this on a platform that is not Windows.

View on HN

Lots of them, but two key ones:

  1. You have much richer libraries available.  There's a
     decent amount of stuff in OPAM these days, but that's
     dwarfed by what you can grab out of NuGet.
  2. You have a great asynchronous/multithreading story.  The F# async
     workflow makes it trivial to write multithreaded apps in
     a similar way to C#'s async/await calls (in fact, F# is
     the origin of that design), and it performs very well.
     OCaml still doesn't do very well with multithreaded
     programs.

You also lose some things, two of which that are most poignant to me:

  1. OCaml is faster than F# for single-threaded programs.
     This has nothing to do with Mono's maturity or speed as
     such, but does have to do with its garbage collector,
     which has not historically dealt well with F#'s allocation
     patterns.  I have not taken time since SGen landed to
     revisit that, though, so the situation might be much
     better.
  2. OCaml can produce tiny self-contained binaries.  Mono's
     AOT gets you the self-contained easily, but you'll be
     looking at relatively large executables.

Thanks, the multithreading is definitely a compelling reason

I've been looking at doing something crazy like building a toy kernel + lisp to sit on top of it for the RPi, and I've been looking at OCamL to do it in. Thoughts, as someone who's used it?

OCaml works great for systems programming (its runtime is orders of magnitude simpler than F# and the CLR). See http://openmirage.org for a bunch of libraries that may be of use to you, such as TCP/IP in OCaml (or https://github.com/mirage)

Brilliant! Cheers :)

Mono's SGen garbage collector is a massive improvement over the older, non-generational GC. SGen still may not be as a good as the GC in the .NET CLR on Windows, but the performance difference is much smaller now (especially since Mono 3.2.x).

Have you tried with F# specifically? Even the old collector generally did fine for C#, but F# tends to allocate a tremendous number of very-short-lived objects, which is where Mono's old GC got unhappy. I actually do fully expect that SGen likely fixes that entirely, but I haven't had a chance to meaningfully benchmark it.

Yes, I have tried it specifically with F#. In fact, I contributed some minor patches to the SGen GC so it'd work correctly on FreeBSD, just so I could run F# on FreeBSD using Mono/SGen. SGen is a significant improvement over the older GC for any program running on Mono, but especially for F# programs.

Feature-wise you also lose a few more things like OCaml modules and functors (and OCaml style objects, which is not a great loss). You gain integration with .NET (and its classes and objects).

There are a few reasons why I use it on Linux over OCaml.

1) Familiarity, if you already know the language, tooling and libraries then you might be better off sticking F# than learning OCaml.

2) Size of community. I'm willing to be proved wrong here, but I find it alot easier to get an F# question, and often more importantly, a question about a library I'm using when I write F# than when I write OCaml.

3) Libraries, Libraries, libraries...

Also the mono runtime is pretty darn good. I agree its not as tuned to handle the small object and lifetimes that functional languages generate but I'm not really running into that limit currently.

About libraries, .NET has a big, complete and really good documented standard library.

With standard library I mean int/float/string/IO/http/xml/async/etc not speaking about stacks of .net (like ui with wpf).

Standard library work really good cross platform with mono, share documentation/stackoverflow with .NET. Mono team fix fast bug when behaviour differ from .NET

Instead of use complex stack like wcf (to create service, partially implemented on mono, webservice ok, soap WS-* less) but bundled with .NET, you can use open source libraries (like nancy, servicestack), change serialization library, etc.

F# use .NET standard library (same library/dll, so a c# answer about StringBuilder class is the same from c# and f#). Can also use every .NET library, bundled with mono/.NET or third party.

i used a lot of F# in the past year for one big reason - access to the dotNet platform. similar to how scala gives you access to the JVM and the massive number of java libraries out there, F# gives you access to a wide and growing body of dotNet tools and libraries out there. in my investigations i found that while the dotNet ecosystem for what i want is smaller than java's it's larger than the OCaml one.

No, you probably don't want to use F# if you can't use the .NET framework.

do you mean the runtime, rather than the framework? my limited understanding of Mono is that it will _run_ most .Net libraries, albeit not as fast.

.NET framework is:

+ runtime

+ core = standard library, io/string/async/thread/etc/linq.

+ some bundled stack, like wcf for create service, wpf for ui, mef for plugin, xml serialization, json serialization, asp.net webforms, etc.

Mono try to reimplement all. Runtime and standard library work very well on mono.

bundled stacks can work, work partially or not implemented, depends (on contribution, check mono website). Some stack are really old way to do things, deprecated, usefull only on windows. Also Microsoft for new stacks (like asp.net MVC) try to open source, so mono need to compile source and fix bug/different behaviour, not rewrite

If you use a library who depends on a bundled stack, can or cannot work on mono. Library who depends on open source or standard lib, should work

Also, Visual Basic and Visual C++ don't have a good support in the mono project.

And obviously you can't use SQL Server or IIS; two components usually used in .Net applications; under unix

Many of the core F# developers develop on Mono first, so I think it's probably reasonable to run F# on something other than Microsoft's VM.

Yes and not, you surely can develop successfully with mono on linux, but .NET is not "write once, run everywhere", is more a "write once, run everything" framework. It's heavy tangled with all the Microsoft and Windows technology and promote the reuse of code in that ecosystem.

That's a rather unique take, given how Xamarin has managed to build a massively successful company around the idea of using .NET to target non-Windows platforms.

a relatively successful company.

Xamarind is a drop in the sea of .NET

Every company that isn't the size of Microsoft is a drop in the sea of .NET.

Reply on news.ycombinator.com