Ask HN: Why isn't F# more popular?
In corporate, especially in MS shops, to modify an old adage, &quot;Nobody ever got fired for choosing C#&quot;.  For side projects, I&#x27;d imagine most people working on those would rather do something not Microsoft-specific.<p>For me, I&#x27;ve done plenty of freelance projects in F# over the past few years and enjoy it.  I&#x27;ve done about two years worth of projects in Clojure, and about a half year in Scala, and F# was the nicest of the three for me.<p>It takes a while to figure out your style however.  Since it&#x27;s a FP-OO hybrid, there are often many approaches to doing the same thing (<a href="https:&#x2F;&#x2F;fsharpforfunandprofit.com&#x2F;posts&#x2F;13-ways-of-looking-at-a-turtle&#x2F;" rel="nofollow">https:&#x2F;&#x2F;fsharpforfunandprofit.com&#x2F;posts&#x2F;13-ways-of-looking-a...</a>) and lots of different &quot;styles&quot; of <i>how</i> FP you want to go.  Some people end up with &quot;C# in F#&quot; and some go almost to &quot;Haskell in F#&quot;.  (I personally end up somewhere in the middle).  And until you figure that out, it&#x27;s hard to be as productive as in a language you already know.  But once you do, I think F# provides the ability to be more productive than C#.  (Granted I think immutable records and `with` syntax would get C# half way there).<p>However I will admit that when it comes time to transition the code back to the owner, I kind of regret using an edgy language.  Fact is most workaday developers don&#x27;t have a ton of interest in new languages and would rather work with something they already know.<p>Most of the pain points are due to running on a runtime designed for OOP.  So even though idiomatic F# code shouldn&#x27;t need null checks or much exception handling, you still need them if you&#x27;re using C# libraries.  There&#x27;s also an annoying mix of camelCase and PascalCase everywhere (the former for logical consistency: a function is a value, and the latter for consistency with C# conventions).