

Announcing a pre-release of F# 3.1 and the Visual F# tools in Visual Studio 2013 - profquail
https://blogs.msdn.com/b/fsharpteam/archive/2013/06/27/announcing-a-pre-release-of-f-3-1-and-the-visual-f-tools-in-visual-studio-2013.aspx?Redirected=true

======
knodi
Who uses F# and why?

~~~
tonyabell
Being serous, who uses Go and why? The reasons are similar to why one should
use F#

~~~
lmm
What? The use case for F# is simple: you have a body of existing .net (i.e.
C#) code you want to interoperate with, but you want a modern functional
language with all the benefits that brings (a real type system, a better steer
towards immutability and purity, etc.). What's the use case for Go? It's
certainly not that.

~~~
Associat0r
F# is general purpose and multi-paradigm, it even has OO classes and
imperative for and while loops. I for one got into .NET because of F# and to
me .NET is just like any other language runtime.

~~~
lmm
OOI why did you choose F# rather than Haskell, OCaml or Scala? I mean sure,
it's a perfectly good language for the more general case (leaving aside the
poor tool support outside Windows and limited deployment options - but
conversely if you're already committed to Windows the tooling is very good),
but there are plenty of comparable options there; the unique selling point is
the .net integration.

~~~
MichaelGG
Here's a comparison of OCaml and F#[1], as F# is "descended" from OCaml.

Mono provides full support for F#. The F# compiler is open source (Apache
license). MonoDevelop has some support for F#, but I haven't used it.

I don't fundamentally see the difference in deploying a runtime like the JVM
over Mono. Mono even lets you pre-compile to native code (that's how the run
on iOS, for instance), so you don't need to install the Mono runtime.

I use F# in production on Linux machines (telephony applications) and have so
for many years. We use Windows to develop, test, build, etc. and then copy
things over to Linux and it just works.

1: [http://stackoverflow.com/questions/179492/f-changes-to-
ocaml](http://stackoverflow.com/questions/179492/f-changes-to-ocaml)

~~~
lmm
>I don't fundamentally see the difference in deploying a runtime like the JVM
over Mono.

It's not a fundamental difference, it's about being confident the tools and
support you need will be available. With the JVM you've got the full weight of
IBM and Oracle behind you, and thousands of vendors selling things like
latency-optimized JVMs, heap analyzers, managed hosting services. Likewise
with the CLR you've got MS and a whole ecosystem of companies building tools
around their VM. With Mono I don't get the same level of confidence that I'm
moving with the herd, that there are many other businesses who will have hit
any possible problems, that I can hire people who've used the platform
before...

But my tooling comment was mostly about the development tools. I'd be super-
nervous about developing on one OS/VM and deploying to another; don't you find
you hit VM bugs that weren't present when you tested?

