Why are C# programmers afraid of F# or functional languages in general?

I am personally interested in learning F# some day, just out of fun to learn new things. I'm sure it would help architecting better C# code, too. I already utilize a lot of delegates and lambda expressions in my code, but a more functional approach could work in some situations. However, F# would be harder to use in real-life projects for one big reason: It would be a maintenance/support risk for companies. If "the only guy who knows F#" leaves the company and F#-projects behind, who could fix it? It's hard to find replacement coder and if found, he would probably be expensive, due to niche knowledge. For personal or open source projects it's not that big deal and when more people utilize F# for those, then there will be people who can code with it.

I guess for me personally, I don't have a lot of experience with the F# syntax and getting started with it I seem to be thrown by really simple things. Also, I notice when writing F# I tend to approach it as a procedural programmer and don't necessarily make use of the optimizations that a functional language like F# offers. Since most of the applications I'm building don't seem to require a lot of data algorithms, I haven't really spent the time learning more about functional languages in general and that's probably hurting me.

I wouldn't say I personally am afraid of it, I've been diving into it lately. I have had many of the struggles explained here with the paradigms and some syntax stuff. But overall I would like learn it more thoroughly just to improve my methods. One of the common reasons I hear for C# developers avoiding it: what's the point? There aren't a lot of F# positions opening up and not a lot of open source projects built with it. So there isn't as much incentive. On top of that many people I've talked to feel that it's merely an academic exercise. They don't feel like the end product is any better just because it's written as a functional application. I would disagree with that personally, and one also has to take into consideration the development process itself as a product. Was it faster to develop? Easier to extend? There is a good possibility that functional programming ends up being much more productive and smart than OOP/C# in this respect. Never say always and never say never. I do see it growing and getting more popular in the future, but I think the slow start is due to lack of career enhancement and a perceived payoff that's pretty low. Both of these things could end up changing this year.

Yes @JeremyCMorgan, I think you've hit the nail on the head with a lot of it, particularly the part about "what's the point?". I think a large proportion of developers out there are so busy just trying to make ends meet, that ventureing into new territory can be incredibly time consuming and difficult. If the day job required it, they'd probably love to start that learning process. As @jemm points out, it's currently still a risk for companies due to the relatively low number of devs in the F# pool, but I hope that changes in the coming months from boths sides, with companies offering more F# positions and developers venturing into F# waters on their own with community support :)

More than anything for me it's time. With only 24 hours before it all starts again I barely have enough ticks to keep up on the technologies I currently use. The thought of learning a different language is about number 10,452 on my list of things to do. It would take someone with a large hammer beating me over the head with these amazing features C# can't do before I'd burn a precious weekend learning F#.

I suspect that F# hasn't taken off yet because it's a long, slow ramp, especially when you combine a language change with a paradigm change. C# took off quickly, but object oriented programming had been in wide use for quite some time beforehand (and it was close enough to C++ and Java for the leap to be easier as well). We're a bit early in the lifetime of the language to have had explosive growth. I also think a lot of developers have a bit of a sunk cost into C# already and if they are going to try something new, they are more likely to try something like node, since the language is a little more familiar and encountering use cases at work is more likely. Personally, I look forward to C# stealing F# features. That will improve both ecosystems, and will also get some C# devs looking towards F# to see what the future holds. That tends to help people jump over as well. Finally, I don't think most of us have had significant pain that the functional paradigm can solve that OO does not. That may change soon, but it just isn't there yet.

what do you think @panesofglass ?

Interesting post by Eric Sink http://ericsink.com/entries/fsharp_chasm.html

@alex_dolin would love your thoughts on this too!

(Not to quibble, but I like to avoid using potentially-pejorative words like "afraid" or phrases like "just can't get their heads around functional paradigms".) Like @mhardy4 said, learning a new language takes time and we're all busy and we have to prioritize. That said, we gotta admit that F# has a LONG learning curve. @mhardy4 wouldn't spend one "precious weekend" learning F#, and the notion that F# could be learned in a weekend is enough to make me spew coffee on my screen. Unless you've been writing a bunch of Haskell or OCaml on the side, most C# devs would need 4 weekends just to become an F# Novice. (Scott W's website helps a TON: http://fsharpforfunandprofit.com/) If you're not going to use F# during the week, what is the motivation to learn it? Well, I could argue that coding in F# is very enjoyable. And it is. But that means it competes with mountain biking or bridge or woodworking or playing with your kids. I think maybe the most compelling reason to encourage C# devs to learn F# is this: Without exception, everybody I know who learned F# would say that it made them a better C# programmer. That's the kind of thing that actually will make a difference during the week.

This is a good piece http://tomasp.net/blog/2015/why-fsharp-in-2015/index.html by Tomas Petricek.

Responding to the original post: > F# projects are difficult to setup and use in Visual Studio in conjunction with existing C# projects? I'm not sure if the words "contrast" or "comparison" were meant or not, but I'll answer that first. You need community owned and maintained templates for many project types, and that requires developers to search for and install them. The templates are not quite as polished as the Microsoft maintained templates in many cases, so I would agree with this point. If "conjunction" was the correct word choice, then I'm afraid I don't understand. F# projects produce IL just like VB and C# and so can be directly consumed by other .NET projects. One may run into some interop problems if discriminated unions or Async types are returned to C#, but these are easily overcome with proper scoping and following the F# Component Guidelines (http://fsharp.org/specs/component-design-guidelines/fsharp-design-guidelines-v14.pdf). > OO developers just can't get their heads around functional paradigms? I always find it amusing when I or others suggest a conflict between OO and FP paradigms. A recent occurrence for me was reading the Reflux (a library used with the React) library's description, in which it claimed to "eschew" the MVC pattern in favor of a functional approach. MVC is considered a fairly foundational OO pattern, and if you compare the original Smalltalk MVC with Reflux, they are hard to differentiate except for the names given to the pattern pieces. Except for a few changes in convention, most .NET developers already use a lot of FP in their apps. LINQ, static classes and methods without state, and various other patterns are essentially the same as one uses when writing functional programs. The difference is largely in the extra amount of typing, unfamiliar operators and keywords, and some additional F# syntax that makes creating certain kinds of types easier. F# has some additional, very powerful features not available to other .NET languages, but most of those are used a lot less than many realize. > There aren't enough jobs around that require the skills so we're not incentivised to learn it except in a few special cases like finance? This has been a valid point and is changing. Startups are beginning to realize the potential for leveraging F# as a way to attract talented developers away from their otherwise satisfactory jobs to try something different just so they can finally turn their F# hobby into a full-time job. Many stable companies are adopting F# in parts of their build or exploratory work (whether they realize it or not). As an example, I used to prototype features with F# and then port them into my C# client projects. F# helped me 1) focus on creating a prototype and 2) see more clearly what I was trying to build without losing me in prescribed patterns or architecture that are often more ceremonial than essential. > Immutable structures just too hard to learn to work with effectively? Not at all. In fact, they let you think less about potential problems like race conditions or unexpected mutations. In C# or VB, they tend to take a lot more effort to create, but their use is very straightforward once you become familiar with the idea that your stuff isn't changing. I used to use this in C# programs, as well. Rather than abstracting things out through things like repository patterns, I would often create internal functions that did the bulk of the work for a class. The public method would receive parameters, retrieve data from a database, then call the internal method to do the work and return the result. Testing was a breeze using the internal method, which was a pure function. > Not enough supporting libraries (e.g. Nuget) available for consumption and use in F# programs Not sure about this one. F# can use anything available for .NET, and several wrapper libraries exist for common .NET libraries, such as FSharp.Control.Reactive for Rx.NET. In addition, libraries like FSharpx, ExtCore, and a few others provide common extensions, while several functional-style web frameworks exist, such as WebSharper, FunScript, Suave, and Freya. > Too hard to write for the web? See the last item re: Suave and Freya. I'm currently working at a company where we use F# for our web APIs. I also built several examples for http://todobackend.com/, and another few examples are forthcoming for Freya and Suave. WebSharper also has an example Todo application available in their CloudSharper web-based IDE. I've given several talks on using F# for web programming, the recordings of which can be found in the Community for F# YouTube feed (http://c4fsharp.net/) and the slides for which are posted at http://panesofglass.github.io/TodoBackendFSharp. I just gave this talk at CodeMash, where I got a great response from several attendees. > Monads are hard? Maybe, but you don't need to know these things. Many computation expressions (F#'s more generalized approach for encoding such concepts) are already available either out of the box (e.g. async) or from a helper library like FSharpx or ExtCore. Several books and, in particular, Scott Wlaschin's series of posts (http://fsharpforfunandprofit.com/series/computation-expressions.html) do an excellent job of helping you understand these things when you find yourself repeating code too often. > If you have used it for production work - at what point did you become comfortable, and if you haven't, what's stopping you? I was comfortable with F# fairly early, as I'd just come to .NET from Ruby and Python (hobby only) and found F# had a familiar feel to it. I started using F# full time for production web-based applications just this year but previously used it to prototype almost all the code I wrote for my work as a consultant. I've also used it to better learn the .NET framework or to deconstruct and understand why certain design patterns are useful, necessary, or just extra noise. If nothing else, F# made me a far better C# developer. I'm delighted I can write F# a lot in my day job now, and I left an otherwise great position to do so.

To be honest, and it's entirely my fault, I haven't realized in which way will functional programming/F# help me. Don't mean just my daily work, I am interested in all aspects of software development and I do a lot of research/pet projects, but I have yet to see about F#. Lots of things to learn, (un)fortunately!

Here's a post on getting pragmatists to use F# https://medium.com/@the_ajohnston/how-to-get-pragmatists-to-use-f-7ad94a728b68