Well, by switching to F# you get much better type inference, discriminated union types, pattern-matching, explicit tail-recursion, serializable types by default, and type providers (and that's not even a comprehensive list). I suppose it depends what type of app you're building as to whether those are worth anything to you -- but in the areas where F# is rapidly getting more popular (data science, numerical/algorithm-heavy work, distributed computing) they do in fact make you much more productive. A good chunk of that productivity gain results from being able to easily and quickly write type-safe code and express algorithms without a great deal of syntactic overhead.

A JavaScript developer might be more productive than either a C# or F# developer depending on what kind of app he/she was writing; overall I don't think that would be the case, especially once you factor in maintenance costs of the code over the long-term.

> A good C# developer can use it without any problem as well.

This is not true (I've been a C# dev for many years already, and I've been learning F# for the last months). It's not so easy to switch the mindset and the syntax.

> PS: a good JavaScript developer will probably be even more productive than both C# and F#, despite the language being horrible.

Yeah, more productive the first days (at a PoC phase), but more productive the next months? I don't think so. You need to watch this talk: http://vimeo.com/72870631

The video is not a good argument. All the time I saved writing Haskell by being able to use quick check was completely torched by having to refactor my entire codebase, with no tooling, when I realized I needed to thread some configuration state all the way down to a tiny area of my code as well as spending a good 4 or 5 days hunting down space leaks.

Overall, I think I would have been more productive with OCaml. Every language has trade-offs, you just have to understand what they are and how they affect the problem you're working on.

The talk isn't about Haskell. Haskell is used just as an example for most code snippets. But all arguments raised in the talk apply perfectly well to F#, and F# has much better tooling than Haskell.