The second annual F# survey
fsharpworks.com
fsharpworks.com
IMHO, if you don't make a distinction between OCaml and SML languages, you should definitely not make a distiction between OCaml and F#.
I have a good experience with OCaml, and judging by most F# code I saw it seems F# and OCaml are much more similar than OCaml and SML.
Here you can see some examples comparing ML variants, which also illustrates my point a little further: http://hyperpolyglot.org/ml
Object-orientation support on OCaml also sets it far apart from SML, for instance. Which can lead to a lengthy discussion, but that's beside the point.
This reasoning, however, is exactly my point: depending on where emphasis is placed, they can be argued to be similar or completely different languages.
The things I know are never coming to c# (like data providers) are not important to me.
So for me c# is the greatest block against f# adoption.
* pattern matching / active patterns
* Discriminated Unions and many other crucial type system enhancements over POCO in C#
* real functional orientation (function composition, immutability by default, partial application)
* type providers (it is not necessarily about data provider)
* more compile time safety harness
* plenty of other things that become apparent when you get comfortable with the language
C# 7 is still doing catch-up with F# 1.
My hypothesis is that it is easier for many people to not try too hard to grasp at functional programming or just learn a new language.
Also most of F# are fairly well experienced C# programmer, and I think they do find the language compelling.
(I mean, without having to learn the rest of the Microsoft ecosystem)
Over half of these people have since said they LOVE F#, and it makes them happy to use it. That it makes them better programmers, and that C# is just verbose and annoying in comparison.
As far as the Windows ecosystem, you don't need to learn much about it, though Visual Studio is a great IDE for F#. But there's IDEs on Linux and Mono specifically says they support F#.
(Honest question. I'm very interested in the question of the approachability of functional languages)
The non-programmers are less positive. From them, I hear "Yeah but it's so concise no one can understand it"[1]. I once got a "If we use F#, then when we exit for (huge figure) we might get less money.[2] Or the general "but this isn't mainstream" (MS's fault for shitty F# marketing.)
And there's also the "ok but we can't find hires". Which is the second worst one. Because on anything that's not some boring CRUD like app, the work to learn the domain and everything about the app dwarfs learning a new language.
(The worst excuse is the nonsense "best tool for the job" as if F# didn't out-class C# in essentially every single aspect. I find this excuse is pulled out a lot, as a way to handwave away real criticism or discussion.)
1: This is just unfamiliarity. In general, less code = less bugs, less work to understand. 2: True if you're selling a business that's a simple website. Not true if you're selling a business that revolves around all your code does.
* Code is less clear than C style (type inference, not used to some pervasive operators like function composition or piping)
* Code is terse and short names are more prevalent (Lost the way to kingdom of nouns)
* There is no Resharper support, and Visual Studio (the main IDE with F# support) tooling is not as advanced as for C#, which is impairing to some extent if you look use the language like a glorified C# and not too used to F# way (tooling is great compared to many other languages IMHO)
* There is no do/while or goto or break
There are also a bunch of F# centric projects (http://fsprojects.github.io/) which might help you to stay in mostly functional programming land and not mingle too much with OOP.
The main difficulty is to get runtime working well, I think Mono has come a long way and is now well packaged and stable enough to get a good experience of the language, thanks to Xamarin who really invested a lot of efforts.
Microsoft is allegedly working on its open source implementation of .NET Framework and runtime, which just landed official F# support, but I think right now the experience and eco-system support has catch-up to do with what can be done with Mono.
Hope this helps!
Ironically, I then jumped to F# since I figured at least the tooling had to be better (since it was a .NET language). I have zero experience with the .NET stack, and my entire use-case for Windows is "use Steam to stream games to my Linux machine hooked up to the TV."
The tooling in a non-VisualStudio, non-Windows way is actually pretty good; Installing Mono is easy, and from there I'd recommend grabbing Visual Studio Code and the Ionide plugin for it. (Or, if you're a vim guy like me, vim-fsharp is also pretty good).
Paket for dependency management is good and kinda like what you'd expect to see in the Ruby world, and and FAKE is a good build system so that you don't necessarily have to touch the nasty MSBuild stuff too much.
There's another project, Forge, in the works for automating away MSBuild's nonsense so that you don't have to deal with it (too much), which is good.
F# is my primary language because it is the best on MS stack.
This isn't a bad thing: knowing the runtime well is a very marketable skill, and helps you write better software anyway. See it as an opportunity rather than a liability.
The more you end up using external libraries, the more you'll have to understand interop between F# and C#. That sort of thing bit me with Xamarin in the past, but it looks like it is getting better (I hope!).
F# was the first cross-platform language from .NET, so it has better supported on OSX and Linux platforms.
I hope there will be more submissions this year!