F# depends on the .NET runtime for everything it does. Yes, you could write trivial programs in F# without delving far into .NET and its standard library. No, you can't go far beyond that without knowing stdlib APIs and using Microsoft's (or Mono's) implementations of said APIs.
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.
Yes. I had experience with Scala which is another ML dialect, and that helped.
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!).
You don't need to learn either C# or Windows programming in general to use F# effectively. .NET is a different story, as it provides a lot of core functionality.
F# was the first cross-platform language from .NET, so it has better supported on OSX and Linux platforms.
I'd say yes if you have exposure to Java library & ecosystem, because .NET Framework's Library has a similar flavor to Java Standard Library.
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.
Yes. I've had several people come onto an F# project with no prior experience in F# or ML or anything like it. They were all able to get up to speed. To start, F# makes it easy to write imperative, C#-style code anyways.
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#.
* 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)
FSharp Power Tools is about all the IDE tooling I care about. I think coming from the OO world developers just expect a whole bunch of add-on tooling. Once you are comfortable with the functional-first way of doing things you find almost all of this unnecessary, except perhaps for some rather basic refactoring support, which FSPT provides.
The other half aren't negative per-se, but they don't seem to care as much (view it as just a job). Or one guy moved to Haskell and then sorta looked down on F#. There's also some frustration sometimes when something hasn't clicked and "should" be easy. Often this is because F# is taught at a high level, without showing the simple primitives that built it up from scratch.
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.
But why?
I mean, F# is a great language, but there are so much options for non-Windows systems with better tooling and ecosystem and larger communities etc.
F# is my primary language because it is the best on MS stack.
Anecdotally: I picked up Okasaki's book on Purely Functional Data Structures as a way of learning FP (to learn Haskell). All the examples were written in Standard ML, so I then started picking up SML. I heard that OCaml was more widely used than SML, so I tried OCaml. The libraries (which stdlib do I use? why is this JSON parsing lib so complex?), build toolchain (oasis? make? corebuild? ocamlbuild?), and cross-platform story of OCaml was another hurdle on top of just the language that I didn't want to deal with.
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.
I find it curious how you treat F# a separate language, but in the "primary programming languages" question OCaml and SML are considered the same language (listed as "OCaml/SML").
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.
Every time I start getting into f# the Roslyn team comes out with new features taken from FP (tuples, local functions, pattern matching) and narrows the gap. So I postpone the move from c# to f# to a later date .
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.
The truth is that F#'s features are not that compelling to justify the move, ML syntax is too different and R# tooling is not there and never going to be.
23 comments
[ 3.1 ms ] story [ 41.9 ms ] threadI hope there will be more submissions this year!
(I mean, without having to learn the rest of the Microsoft ecosystem)
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.
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!
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)
* 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
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.
F# is my primary language because it is the best on MS stack.
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.
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.