+1 I also say that language polyglots are generally a much better find than those who build their career around a single language to rule them all. Although some of us promote JS as pretty close to that, even JS has a C/C++ base under the covers.

It's hard to get any new system to be seen seriously. It took the better part of 3-4 years for NodeJS to see any traction, and even then it's misunderstood. I continuously see people following the same patterns in building Node modules as they would for C# libraries.

It looks like you've at least tackled what is a very hard part in many organizations, and that is infrastructure. Not to mention, the new code can intermingle with the old (at least for a while).

I like FP paradigms, I find that it definitely leads to better unit test coverage... Not that unit test coverage is everything.

Maybe so; though job ads I'd seen for F# seemed to have higher salaries. Possibly that was just because of where they're based (London salaries are way higher than here, for example)

Because F# + London = Most likely to be a investment bank or finance.

Which is really annoying because I want to do functional programming, but the only place they employ those programmers in the UK is london.

Well, nothing stops you from trying it out and seeing what happens, right :-)

Post a job ad explicitly requiring functional programming experience and I'll bet an enthusiast will end up on your doorstep soon enough. Then you can see whether your fears hold or not.

The job ads for F# usually do have higher salaries than those for C# programmers. However, I think you misunderstand why that is the case; it's not (just) because good F# developers are harder to find than good C# developers, it's because a good F# developer will be more productive, even more so than reflected by the salary ratios. A good F# developer is (almost always) going to also be very proficient in C# too, so they'll be able to switch back and forth easily and use whichever language is better-suited for a specific project.

Please don't put F# on a shiny golden pedestal. A good C# developer can use it without any problem as well. You of course would need to be open-minded enough to understand that a C# developer doesn't mean an imperative developer. I am not the best developer at all, but my C# code tends to be quite functional and I prefer using the Maybe monad to deal with nulls in some cases for example. I just don't see any massive obvious benefit of loosing the tooling and ReSharper to switch to F#. Especially now that C# is open-source and the Roslyn is nearly there.

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

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.

Where is "here", in this context?