Re:Announcing a pre-release of F# 3.1 and the Visual F# tool...
by MichaelGG on Friday June 28, 2013 @01:50PM
(#5959346)
Plenty of different reasons. Personally, I'm looking for a solid language with broad library and interop, and fantastic tooling (from editors to debuggers, profilers, and more). .NET has a good ecosystem; MS loves developers (usually).
F# has nearly a superset of C#'s functionality, but with a far better fundamental design. It requires much less code, and results in far fewer bugs. And the biggest tradeoff is that Visual Studio's IntelliSense is a bit less capable with F# than C#. Performance wise, F# usually matches C#, but has more flexibility to outperform it in some cases.
The F# team has a strong background: They were the ones responsible for bringing proper generics to C# and the CLR. Without them, the CLR would probably have a lame generics system, such as Java. F# also demonstrated how to properly do async on .NET half a decade ago, which C# 5 finally picked up.
So if you're on .NET, there's little reason to not use F#, unless you're in a shop that needs replaceable warm-body programmers.
If you're not on .NET, there are perhaps better languages (Haskell), but that comes at a cost of having less tooling and libraries.
F# has nearly a superset of C#'s functionality, but with a far better fundamental design. It requires much less code, and results in far fewer bugs. And the biggest tradeoff is that Visual Studio's IntelliSense is a bit less capable with F# than C#. Performance wise, F# usually matches C#, but has more flexibility to outperform it in some cases.
The F# team has a strong background: They were the ones responsible for bringing proper generics to C# and the CLR. Without them, the CLR would probably have a lame generics system, such as Java. F# also demonstrated how to properly do async on .NET half a decade ago, which C# 5 finally picked up.
So if you're on .NET, there's little reason to not use F#, unless you're in a shop that needs replaceable warm-body programmers.
If you're not on .NET, there are perhaps better languages (Haskell), but that comes at a cost of having less tooling and libraries.