4 ms·

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 signif

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.

jnazario 13y ago
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.
mtct 13y ago
No, you probably don't want to use F# if you can't use the .NET framework.
- untothebreach 13y ago
  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.
  - enricosada 13y ago
    .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
    - mtct 13y ago
      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
- gecko 13y ago
  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.
  - mtct 13y ago
    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.
    - gecko 13y ago
      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.
      - mtct 13y ago
        a relatively successful company. Xamarind is a drop in the sea of .NET
        bunderbunder 13y ago
        Every company that isn't the size of Microsoft is a drop in the sea of .NET.
gecko 13y ago
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.
- untothebreach 13y ago
  Thanks, the multithreading is definitely a compelling reason
- girvo 13y ago
  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?
  - avsm 13y ago
    OCaml works great for systems programming (its runtime is orders of magnitude simpler than F# and the CLR). See http://openmirage.org 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 https://github.com/mirage)
    - girvo 13y ago
      Brilliant! Cheers :)
chollida1 13y ago
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.
- enricosada 13y ago
  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.

jnazario 13y ago

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.

mtct 13y ago

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

untothebreach 13y ago
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.
- enricosada 13y ago
  .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
  - mtct 13y ago
    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
gecko 13y ago
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.
- mtct 13y ago
  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.
  - gecko 13y ago
    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.
    - mtct 13y ago
      a relatively successful company. Xamarind is a drop in the sea of .NET
      - bunderbunder 13y ago
        Every company that isn't the size of Microsoft is a drop in the sea of .NET.

gecko 13y ago

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.

untothebreach 13y ago
Thanks, the multithreading is definitely a compelling reason
girvo 13y ago
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?
- avsm 13y ago
  OCaml works great for systems programming (its runtime is orders of magnitude simpler than F# and the CLR). See http://openmirage.org 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 https://github.com/mirage)
  - girvo 13y ago
    Brilliant! Cheers :)

chollida1 13y ago

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.

enricosada 13y ago
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.