Take the 2-minute tour ×

What do you think of the F# language? I would like to learn it's positive and negative points.

What is your experience with this language? When should or shouldn't someone use F#?

See also: F# at Microsoft Research

share|improve this question

closed as not constructive by MichaelT, gnat, Kilian Foth, thorsten müller, Bart van Ingen Schenau Apr 17 '13 at 10:57


I think its F#ing awesome. –  Will Sep 13 '10 at 11:58
I'm really interested in using F# in a real-world project after thoroughly enjoying my short time learning Haskell, so a concise couple of answers on F# might be enough to get me and other programmers to adopt it for a few projects. –  Mike B Sep 13 '10 at 13:27
Clojure is better! –  Job Dec 30 '10 at 4:07
@Job: Because... –  Robert Harvey Jan 4 '11 at 2:48
F# is a two letter word. Just kidding. I've had a look at it and I thought it was interesting 'cause I have never seen anything like it (which says more about me than about F#). –  Diego Deberdt Jun 24 '11 at 19:07
add comment

7 Answers

up vote 23 down vote accepted

I have mixed feelings about F#. I have a strong functional programming background and many years of C# experience, so I can see it from both sides and I think that F# makes too many compromises to satisfy people from either group.

It's worth pointing out as well that .net is fundamentally an object-oriented imperative execution environment. It's not terribly well suited to a language like F#, so there are compromises to be made everywhere. At the end of the day, all F# programs need to be turned into a pile of CLI types and methods which, largely, have C#-like semantics.

There is a lot to like about F#, but I'm going to focus on the negative here, since the good things are more obvious and well documented.

  • F# is very awkward as an imperative language, and a lot of the more imperative .net APIs end up feeling very clumsy (XmlTextReader I'm looking at you). An attempt to address the use cases that break/continue/return satisfy in C# (without involving computation expressions) would go a long way here.

  • F# is somewhat compatible with a vaguely-defined subset of ocaml. This leads to cruft, lots of deprecated syntax and weirdness. Even worse, it seems to have no tangible benefit--it's not like F# programmers are reusing ocaml libraries. I understand why one might have done this in a research setting, but this should have been cleaned out of the language long ago.

  • F# should have left out the "module system" if they didn't intend to do it right. An SML style module system (structures, signatures, functors) would conceptually work very well in F#. F# signatures are really just an alternative way to enforce visibility and don't actually serve to provide polymorphism like SML's signatures do. F# has generic types, but lacks generic modules. Lame lame lame. That said, a generalized higher-order module system like SML's would be very hard to represent directly in terms of the CLI. This would require a lot of effort to do right, and would probably cost considerably in compile time + code size.

  • The anonymous function syntax is too verbose. It's downright depressing that C#'s lambda expression is cleaner.

  • Calling into the .net api feels a little bit like doing interop--it's awkward to invoke methods with tuple'd arguments and you constantly end up converting data types (especially list -> array). This is probably difficult to fix--there are a lot of trade-offs involved in fitting an ml family language into the .net environment.

  • F#'s type inference is closely related to ML's, but F# has to cope with overloaded CLI methods. I would have been happier if they had used a type inference scheme that supported deferral, since this would significantly reduce the number of required type annotations when interfacing with .net libraries.

  • The compiler is unacceptably slow, especially on mono. We're talking hundreds of lines per second slow. I have a 4kloc F# program that takes 16 seconds to compile on a core 2 duo macbook pro. That is ridiculous.

share|improve this answer
Wow, you guys create impressive feedback on this question... Applauds, maybe I'll give out a good bounty in the future but I would love to reach the additional moderation features first (to help out the community if you don't mind). This seems like a sufficient reason to stay with C# until F# has been improved to counter these negative points, anyone that disagrees with my decision and blucz's bullet points is free to add an additional answer referring to his points. –  Tom Wijsman Sep 12 '10 at 23:14
I doubt that many of these points will be addressed, other than perhaps compiler performance, which is admittedly much worse on mono than it is on windows. I am using F# for a project right now, and it is saving me time over C# despite these downsides, so it's not all bad. Especially if you don't know any other functional languages, I urge you to give this a shot--it will show you a new way to look at the world and make you a better developer. –  blucz Sep 13 '10 at 4:31
You make some good points. The way I look at it though is that no language is perfect. The fact that this language is first class in the .NET world means that more companies are going to take functional programming seriously. –  ChaosPandion Sep 13 '10 at 14:26
Agree on the comparison with C# lambdas. Seems weird that the OO language has the terser/cleaner syntax. –  User Jan 9 '13 at 2:15
add comment

What do you think of the F# language?

I love it!

I would like to learn it's positive and negative points.


  • Productive. F# captured the essence of ML that makes it such a hugely productive programming language.

  • Efficient. F# captured the simple mode of compilation that makes the performance of ML code so predictable and .NET 4 makes it predictably fast.

  • Interoperable. F# solves my single biggest gripe with previous-generation languages by providing safe high-level interoperability with the rest of the .NET platform. Scala and Clojure do the equivalent for the JVM.

  • Exciting. The F# community are buzzing with enthusiasm and continue to amaze me with their incredible work, solving real problems and helping people. Our customers are using my work to do everything from building robotic trains to futuristic stethoscopes. I love being a part of that.

  • Commerce friendly. Most of the F# community value my hard work and are willing to recompense me fairly for it. Clojure is another upcoming language built by an industrialist for industry and I have great respect for that.


  • Compiler is slow enough that you really start to feel it after ~50kLOC.

  • Indentation-sensitive syntax means no autoindenting.

  • F# doesn't have every academic language feature under the sun for me to tinker with when I should be solving real problems.

What is your experience with this language?

I've been building products and providing services around F# for 4 years.

When should or shouldn't someone use F#?

Impossible to say without more specifics. Find little projects and give it a try. I'm sure you'll be amazed. :-)


share|improve this answer
Slightly OT, but you mention Scala and Clojure. Which one of them do you think is more ready for the real world? –  John Reynolds Dec 29 '10 at 21:47
I don't have enough experience with either language to say anything authoritatively but the fact that Rich Hickey has a lot of industrial experience and is trying to commercialize Clojure makes me lean in Clojure's direction. Martin Odersky has started a company (Scala Solutions) to help industrial users of Scala but I think it is too early to say anything much on that subject. You may appreciate this thread: scala-programming-language.1934581.n4.nabble.com/… –  Jon Harrop Dec 30 '10 at 2:31
Thx! Interesting to (once again) note how conservative the Java world is. –  John Reynolds Dec 30 '10 at 12:32
Yes, I'd love to see more innovation happening outside Windows/.NET. That's why I'm working on HLVM. Here's the official "Scala in the Enterprise" web page listing commercial users of Scala: scala-lang.org/node/1658 –  Jon Harrop Dec 30 '10 at 14:25
add comment

Here are a few reasons F# is a great language to learn:

  1. Immutable by default
  2. Can be mutable (Just in case...)
  3. Pattern matching
  4. Monads
  5. It is object oriented so interoperability with C# is not a problem.

Check out this little piece of my parser that uses partial active patterns to match productions in the ECMAScript language.

let (|KeyWord|_|) element =
    match element with
    | IdentifierName token ->
        let isMatch = keyWordSet.Contains token.value
        if isMatch then Some (element, token) else None
    | _ -> None

let (|FutureReservedWord|_|) element =
    match element with
    | IdentifierName token ->
        let isMatch = futureReservedWordSet.Contains token.value
        if isMatch then Some (element, token) else None
    | _ -> None

let (|BooleanLiteral|_|) element =
    match element with
    | IdentifierName token ->
        match token.value with
        | "true" | "false" -> Some (element, token)
        | _ -> None
    | _ -> None

let (|NullLiteral|_|) element =
    match element with
    | IdentifierName token ->
        match token.value with
        | "null" -> Some (element, token)
        | _ -> None
    | _ -> None

let (|Literal|_|) element =
    match element with
    | NullLiteral (element, token)
    | BooleanLiteral (element, token) -> Some (element, token)
    | NumericLiteral token
    | StringLiteral token
    | RegularExpressionLiteral token -> Some (element, token)
    | _ -> None

let (|ReservedWord|_|) element =
    match element with
    | KeyWord (element, token)
    | FutureReservedWord (element, token) -> Some (element, token)
    | _ -> None

let (|Identifier|_|) element =
    match element with
    | ReservedWord (element, token) -> None
    | IdentifierName token -> Some (element, token)
    | _ -> None


When you specify an active pattern like (|...|_|) you are telling the compiler that a match won't always be made for this pattern.

This production in the ECMAScript language:

Identifier :: 
    IdentifierName but not ReservedWord 

is matched with the following code

let (|Identifier|_|) element =
    match element with
    | ReservedWord (element, token) -> None
    | IdentifierName token -> Some (element, token)
    | _ -> None

Another way you can write an active pattern is like this:

let (|Even|Odd|) number =
    if number % 2 = 0 then Even else Odd

Notice that every number passed in will return a match.

let doSomething number =
    match number with
    | Even -> printfn "%i is an even number!" number 
    | Odd -> printfn "%i is an odd number!" number 
share|improve this answer
I've only seen some basic of F# in the past but now that it's a first class language (can be used in VS, ASP.NET, Silverlight, ...) I'm wondering if I should look into it and stop programming in C# (for personal projects). From university I do understand pattern matching and your code looks indeed a lot more handy than a lot of switch/if structures, but I don't completely understand it... If you want to, could you explain one of the matchings a bit? What is the (|...|_|) syntax, it seems new? –  Tom Wijsman Sep 12 '10 at 17:22
@TomWij - See update. –  ChaosPandion Sep 12 '10 at 17:38
@ChaosPandion: Thank you! Understand the whole thing now, it's indeed a really handy way of doing conditions. :-) –  Tom Wijsman Sep 12 '10 at 18:42
@TomWij - No problem, explaining it also helps me understand it better. –  ChaosPandion Sep 12 '10 at 19:05
One quick reaction to what you write, not based on any experience with F#: immutability by default, but mutability on demand strikes me as aiming for the worst of both worlds. Immutability seems to me primarily valuable for reasoning about the program, and allowing mutation subverts that. –  David Thornley Sep 22 '10 at 21:24
show 1 more comment
  • Pattern matching -- The biggest dream feature
  • Active Patterns -- One plus
  • Higher-order functions
  • Imperative programming -- No need to think TOO functionally like Haskell.
  • Computational expressions -- This is more powerful than monads, type-wise.
  • Indentation syntax

The problems are:

  • Compiler is too slow
  • .NET pollutes the functional part and introduces weird syntaxes
  • Curried function argument order problem (function subject object or function object subject or function acti)
  • Curried vs. Uncurried problem
  • F# functions vs. delegates problem
share|improve this answer
I've also seen the Nullable VS Option problem, but after I read an article about that I tend to think that for that and the F# Functions VS Delegates problem it's better to prefer the F# ones... Syntaxes and order might indeed be something weird when coming from C#, I'll have to see if that is reasonable or not... By compiling I guess you mean source to byte code, I'll have to accept that I guess. Let's hope that mainly I/O is the issue there as then a SSD could handle that... –  Tom Wijsman Sep 12 '10 at 21:54
The speed of the compiler is not a real issue in my opinion. The compiler will optimize the heck out of your code and shows in performance tests. Also the key to dealing with the impedance mismatch between delegates and F# functions is to expose objects to the public rather than F# constructs. The design of the language makes this relatively easy. –  ChaosPandion Sep 12 '10 at 22:20
@ChaosPandion: What do you mean by exposing objects? Are those F# Functions or Delegates? Feel free to use a permanent pastebin.com to describe this, don't spend too much effort on it (unless you do it for better understanding I don't want to annoy you). :-) –  Tom Wijsman Sep 12 '10 at 23:05
@TomWij - Hopefully this properly shows what I mean. pastebin.com/8S0Ku4t1 –  ChaosPandion Sep 13 '10 at 14:23
Yes, it does, thank you. :-) –  Tom Wijsman Sep 13 '10 at 15:05
show 1 more comment

As a C# programmer who has recently been exploring F# by reading The F# Survival Guide, I can't help thinking that if I'd been exposed to it back when we were still using C# 2.0, I would have thought it was awesome. Now, however, that C# 3.0 has added LINQ and type inference and anonymous types and lambda expressions and all the fun with IEnumerables, I feel like all the things would have been better expressed in F# can now be expressed pretty damn well in C# too.

Also, as a stylistic judgement, my gut feeling that there was way too much going on with punctuation. Too many pipes and underscores and multi-symbol constructs like [| and -> and (| and (_). Reminded me of Perl. I just find that too much meaning attached to punctuation makes for completely unreadable code.

share|improve this answer
Pattern matching? –  Jon Harrop Dec 27 '10 at 20:12
@Jon: Good point, that is indeed something from F# which still looks awesome compared to C#. –  Carson63000 Dec 28 '10 at 22:59
add comment

Well, I wanted to write a simple application to connect to a MySQL database and do mathematical functions on the data. Running functions on data seems to be a natural fit to a functional language.

That didn't work well (you can find remnants of the project as questions on StackOverflow). My take-away from that project was that the MS database libraries are ridiculously duplicated and hard to use. Further, the imperative paradigm is hard to directly map to F#.

Also, the syntax is 'relatively' easy to read, but very hard to understand well enough to write in a non-trvial fashion. I found at the time (2008) a terrible gap between the "hello world" tutorials and the advanced technique discussion. Today, a problem is that the language has evolved so that the early material on it breaks when compiled today.

I have a generalized gripe about whitespace delimiting in general, and F# unfortunately falls in that bucket.

So I didn't have a good experience with it. But, I think if you have a full-time project with it, in a domain that maps well, F# is going to be a right solution (Along with Haskell, OCaml, and Lisp).

share|improve this answer
I wish I could understand the gripe people have with white space delimited programming. –  ChaosPandion Sep 22 '10 at 21:17
@Chaos: Basically it makes editing more hassle than it needs to be. I run into a whole gamut of problems when I'm moving scope around in Python. F# gets tetchy about tabs vs spaces. All of the hassle can be removed with braces. –  Paul Nathan Sep 23 '10 at 14:13
You know I have run into a few issues since I started using F# but in general I seem to write shorter function with very few reasons to indent. –  ChaosPandion Sep 23 '10 at 15:28
It also means you cannot paste badly formatted code from somewhere like a blog and have the IDE autoindent it for you as you can with OCaml, for example. I really miss that. Also, translating code from OCaml to F# really highlights just how little it buys you: a few ins and the odd begin..end. –  Jon Harrop Dec 27 '10 at 20:11
add comment

I didnt like how classes require me to name the this pointer instead of allowing me to access member variables implicitly. That was the #1 reason for me not to continue learning it. I felt if i cant access member vars easily that many other things will not be easy as well.

I also wasnt impress with the go programming language. However i do like boo even tho i never programmed with it.

share|improve this answer
add comment
