Ask HN: Why isn't F# more popular?

I love F#. Switched over from the other .NET languages as soon as it came out and I haven't looked back. F# helps me to become a better programmer.

What's wrong with ti? I wish F# had more OCAML to it. Functors would be cool.

Why isn't it more popular? Sad to say, most programmers don't really care about being a better programmer. They care about getting a job, keeping a job, and getting promoted -- none of which might involve learning a functional language.

To be fair, there's also a different paradigm programming functionally with larger development teams, a skill that many shops haven't mastered. Three guys in a startup would be fine. Three hundred guys in a mid-sized firm could have a lot of problems switching over. I grok that.

I'm kind of surprised F# is as popular as it is. Microsoft deliberately downplayed it when it came out, calling it a "scientific" language. I think that coders realize the open source power the language brings to *nix boxes, the more popular it'll get.

Let's put it this way: there are a ton of other languages I've wanted to try, but so many of them just aren't "done" yet -- there's still a crap ton of things missing. F# isn't like that. You pick F# up, you can code just about anything, and the community is there for support. I don't see that advantage changing any time soon.

What's surprising is that Scala/Java basically has the same issues, but Scala seems to be more popular due to early adoption by several industry actors (Twitter IIRC).

Agreed. At some point, if your language(s) of choice are decently powerful and you are decently good at them, you don't feel yourself shackled by a lack of agility, expressivity, or capacity for producing something of quality. Rather, you feel fluent. I mean, I feel a little uncool having never more than dabbled in functional-first languages. But I'm also an adult who has shipped multiple products without any undue tooth-pulling and rather enjoyed the process. So it's hard to take my feeling of uncoolness all that seriously.

And then the motivation to pick up not only a new language but a whole new paradigm just doesn't seem that urgent or appealing, especially when compared to that new bit of infrastructure which will oh-so-obviously add a significant new tool to your toolbelt.

That's because it hasn't been around for that long. But I defiantly know of companies starting to introduce it.

In corporate, especially in MS shops, to modify an old adage, "Nobody ever got fired for choosing C#". For side projects, I'd imagine most people working on those would rather do something not Microsoft-specific.

For me, I've done plenty of freelance projects in F# over the past few years and enjoy it. I'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.

It takes a while to figure out your style however. Since it's a FP-OO hybrid, there are often many approaches to doing the same thing (https://fsharpforfunandprofit.com/posts/13-ways-of-looking-a...) and lots of different "styles" of how FP you want to go. Some people end up with "C# in F#" and some go almost to "Haskell in F#". (I personally end up somewhere in the middle). And until you figure that out, it'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).

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't have a ton of interest in new languages and would rather work with something they already know.

Most of the pain points are due to running on a runtime designed for OOP. So even though idiomatic F# code shouldn't need null checks or much exception handling, you still need them if you're using C# libraries. There'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).