Ask HN: Why isn't F# more popular?
I'm coming from Python world and I just started learning F# for fun (and profit ;)). So far, my experience with the language was quite positive, so I was bit surprised to see that F# is not more popular. I guess I wasn't able to see its downsides just yet.
My question for more experienced F# programmers: What are the F#'s downsides which prevent its more widespread usage?
For other people who have tried F# and didn't continue to use it: Why did you stop? Do you use other functional languages instead?
General questions: Is it because of its ties to Microsoft and/or Windows? Is F# not as good as other functional languages (which ones are better, and why?)? Not enough learning resources, examples, etc.?
114 comments
[ 0.28 ms ] story [ 191 ms ] threadalmost nobody is using erlang. one of the best languages out there.
Actually, that's a myth.
One of the reasons why Betamax lost is because a tape could only contain one hour of film, so you needed at least two tapes for a single movie. VHS didn't have this limitation.
The only reason js has any success at all is the web.
Another aspect is the fact that many of the Javascript's problems were actually not problems of the language itself but of the environment around it, like DOM and AJAX implementations in different browsers.
Besides those major problems, the language itself has some minor problems. But as you pointed out the language has a very active ecosystem around it, which creates at least 5 solutions to every problem. But many solutions involve new languages which compile to javascript. So practically the problems are solved but the theoretical use case of writing plain Javascript is still a little problematic.
It is not even object oriented, so instead it is commonly used with the prototype approach.
It is not a functional language either as functions can define global variables, therefore they aren't actually functions. And defining global state is the default behaviour.
This is why there have been so many languages built on top of it.
Why did you choose JS again?
If you write a lot of F# then if anyone leaves you need to replace them and it's harder than finding a C# developer.
Secondly most of the libraries you interop with are C# and so you have to go through interop which is more annoying.
https://fsharpforfunandprofit.com/posts/completeness-seamles...
Also, from what I've read it's easy enough to use F# code from C# if you wrap it in an object. F# is multiparadigmatic, including support for FP and OOP.
Proprietary platform are less popular. And .net is was very closed at the begining.
Non cross platform languages are less popular. And mono is not really that great on linux.
Plus the usual communication, timing and hype factors.
Oop is just a strut with functions and a fancy dress. It's not really a new way to think.
I trained many, many, many people in small groups in programming. The functional concepts are always the hard ones to explain.
And as a dev, even when i deeply understand the benefits of immutability, i find it often being a huge constraint for the most mundane tasks.
Most programmers make simple programs. They don't need complex tools.
Lower level is harder no matter the paradigm.
The features I mentioned are functional no matter the level.
it seems to me you're just not a fan of static type checking.
Also since all popular and dominant languages are either Object Oriented and/or Imperative, functional programming concepts seem too alien.
Even though I consider myself a fairly passionate programmer, I haven't found enough incentive to invest proper time to learn a purely functional language. The infatuation with Clojure and Haskell only lasted for a weekend for me. I always think, that next month I am going to invest in learning a functional language, but always something else more shiny comes along from other domain like, Dynamo DB, Firebase, RabbitMQ, etc. Which I find more practical to learn rather than learning yet another programming language.
I mean, I know a ton of obscure and esoteric languages. Do I turn to them, even the cool ones, when I want to implement some idea I have? I'm afraid I often turn to the tried and tested boring languages because of the network effect. Increasingly I just use raw javascript, which is right up there with VB and PHP for unpopularity, just because it makes it damn easy to share the result with others if its in a web-page.
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.
I consider myself fluent in Python.
But in my case, that was the extra reason to try to learn something new and different, and after searching for a suitable second language, I kinda settled for F#. (I have also tried Haskell, but never managed to move past some basic examples)
- it's hard to hire people
- most libraries are written for OO style so most code will be written OO style
- most sample code is written in C#
- C# is a pretty nice language. Does F# really provide an advantage?
- will MS abandon F#?
I really would like to see a clear case for F#. When you consider factors like hiring and existing ecosystem the case for F# is not clear to me.
Many other commentators said something like this, so it seems to me that:
Not many people are using F#, because it's hard to find employer who needs F#. And employers don't seek for F# programmers, because there are too few of them.
Another data-wrangling thing easier in F# (not FP in general) is type-providers.
Productivity isn't always measured by direct output. If I write something with 20% overhead that is 3x more robust, then it's worth it. This is what I see F#/Clojure/Haskell providing.
However, functional programming languages are not highly popular. Most programmers never learn any functional programming languages, choosing instead to learn one of C#, Java, C++, Javascript and stick with it indefinitely. For that reason, F# is stuck in a position of being the number 3 .NET language under C# and VB.NET.
That final point is a different topic again: F# is under VB.NET. Few consider Visual Basic to be a great language; it survives on momentum alone. F# is comparatively new; momentum takes decades.
Now if you're talking generic functions and higher order functions, maybe. But those are rarely needed, as you rather want a tuned specific version instead - or a template.
* https://hackernoon.com/why-isnt-f-the-king-of-net-2a9a1963e0...
* HN: https://news.ycombinator.com/item?id=12530265
https://youtu.be/aJXzY9vhqZg?t=339
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.
For another, I think it really boils down to maintainability. Elsewhere in this thread, there is a comment that "return to your code in 6 months and it's incomprehensible." As a guy who worked with a large Scala codebase, I totally "get" that, but the thing with "functional code you haven't seen in 6 months" is: It's either incomprehensible or it's MUCH easier to reason about than stateful OOP code. And the "incomprehensible" stuff tends to fall into a couple different categories (lifting and conversion, complex function composition, etc.) that gets at least a _little_ better once you've hit your head against them a few times.
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).
If the side project is to learn something new, the language is usually what I'm trying to learn, so it's harder to pick what to build rather than which language to use.
Could you give some examples of what did you do in F#? Did you choose F# just because you wanted to see if you can do it in it, or did F# have some advantages over other (functional) languages?
> It takes a while to figure out your style however. (...) Some people end up with "C# in F#" (...) And until you figure that out, it's hard to be as productive as in a language you already know.
My plan is to avoid as much as possible "writing Python in F#", because I choose F# as an opportunity to learn something new/different (which might transfer to writing better Python later). Any tips for this?
Compared to Python, I'd assume that 1) I write a bit less code to solve the same problem in F# as I would in Python, 2) it takes a bit more time, but it is more fun, 3) once it compiles, there are seldom any bugs.
So technically you trade some of programming speed for less time spent in debugging and writing test code. In the end, you are way faster and more productive. Especially once the code base starts getting bigger, the type system starts bringing in extra benefits.
Major point is that detecting and correcting bugs in editor is faster than in compilation, and in compilation is better than at testing. So compared to Python, you get 2 orders of magnitude of better and faster development.
My personal landing point is about #6 in the turtles article. I still like classes and interfaces and think they fit perfectly well. However, inheritance is something I avoid completely now. The effect can be done much more flexibly and transparently by several other means. But one great thing about classes is that you get nice autocomplete when you type `myservice.`. And note I only use OO for "services"; data is data is data. So if you're doing DB stuff, prefer an anemic data model and a platform that supports it (so Dapper rather than EF or NHibernate). Basically do `db.Save(myData)` rather than `myData.Save()`.
Another big change I've noticed is I don't use "private" functions much anymore. In OO I spent a lot more energy making sure that people using my classes couldn't use them wrongly. They could only do exactly what the requirements allowed. I think OO mindset (at least in C#/Java, maybe Python is different) makes you paranoid and guides you to putting "app code" into what should be "libraries". This sometimes made e.g. unit testing more of a pain; you can't test your "validate" functions directly because they're private. Now I tend to open most everything up and let developers do what they want with my code, but I add a few helper functions to cover the common cases to guide them in the right direction. In general I consider everything a library now; the only "app-specific" code I write goes in `main` function that glues everything together. Of course I still don't open functions that expose contained services, or that leave things in an inconsistent state, but that's about all.
And of course embrace immutability and recursion (or the library functions that do it for you).
Probably the most annoying thing for you, especially coming from Python, will be "similar records". So you'd need a `User` that just has raw data, `UserDb` that maybe has that plus an ID/DateAdded/DateModified, a `UserOut` that maybe has that minus PasswordHash, a `UserIn` that maybe has RawPassword/RawPasswordAgain, etc, and conversions between them all. Not to mention if you want different schemes for jsonNaming, db_naming, RecordNaming, etc. I've yet to come up with a happy typesafe way of doing this.
Why is this needed in F#? Something to do with immutability?
I am sure there could be a good way to automate this using type providers, but I haven't tried it yet.
https://gist.github.com/daxfohl/0183db108924ee87440928cb803d...
One set of use-cases where pattern-matching are particularly valuable is parsing and other times when you're deconstructing / transforming a complex structure.
One use-case for a type provider would be, say, taking an XML schema and exposing its structure as a compile-time constraint.
One set of use-cases where computation expressions are valuable relate to (oh god I don't want to use the "M"-word) the creation of a small DSL that isolates some type of specialized computation on a parameterized type. For instance, the (built-in) `async` computation expression.
Those might sound like fairly esoteric use-cases, but they're really not that uncommon if you do DSL / library development.
Thank you for your kind words!
As I mentioned elsewhere, I have also tried Haskell, but I never managed to move past some basic examples. With F#, at least for now, it seems like I can more easily read/understand even more complex stuff (and one day maybe even write it by myself).
To me, Windows has eclipsed both MacOS and Linux as the best dev environment. It's caught up in shell and the whole ecosystem of tools completely blows away what exists on MacOS and Linux.
Windows is also a lot better than the other two in keyboard shortcut support.
I don't really understand what you mean about keyboard shortcuts though. I thought the windows ones are hard coded into the OS and can't be changed?
I think it depends on what you are used to though.
Interesting. Why do you say "including languages that haven't been invented yet"? Does F# have some features that are modern / good, but not common in some other current languages, but are likely to be there in future ones?
>What are the F#'s downsides which prevent its more widespread usage?
The two biggest downsides I've encountered are not related to the language itself. One is lagging support in Visual Studio (didn't support folders for long time, poor cross-language C#/F# navigation, no support in .NET Core projects etc.) and the other is the lack of examples/frameworks for WPF applications when I needed them.
Other than that it's my favorite language for all kinds of tasks -- from production apps to scripts.
I use VS Code, both for Python and now for F#, and so far my experience has been positive. But that might be because I've used F# only for very basic stuff, and I don't know how better it could be in some other language and/or IDE.
> scripts
I think I'll stick with Python for that :) But I'm thinking about maybe transferring some machine learning stuff from Python to F# in (some distant) future.
I've used PyCharm before, but currently VS Code seems like the right balance for my needs.
F# makes sense when a) functional programming has a history of being advantageous in the domain, b) there is a mandate or clear advantage to develop in the .net ecosystem, c) a founder or engineering team has serious expertise with F#. Even then you have to ask if a functional-ish C# codebase you can easily add 50 developers to if needed is good enough.
Almost every cool feature about F# you show to a C# developer he'll go "OK I can sort of do that in C# it's just a bit more tedious".
When you add up those incremental improvements you get drastically shorter code but that is not immediately obvious and that's why you'll have a hard time convincing C# developers switching to F# is worth it.
Also F# has it's own warts, like compilation order based resolution :(
It's sad because F# is a fine language. Just not a popular one.
On the F# slack channel I asked what was the compelling reason for F#, why isn't it more popular, and basically there wasn't one. There's some stand out language syntax like computation expressions. The community is really good, but F# specific libraries are very quiet, web libraries like suave are ok, but kind of lifeless.
More interestingly, when I shifted a bunch of F# projects to C#, it was relatively straight forward. C# has enough syntax to do a lot of things functionally (though not as concise)
Java and Objective-C are far behind as languages, so the motivations for Scala, Clojure, Kotlin, Swift were far greater.
There are some advantages with stronger functional languages. Though C# seems to be slowly but surely working out how to incorporate more functional ideas. Though never will be a "functional language" but will support a functional approach.
- Microsoft had no real support for using it in web projects.
- Functional programming would be great for data transforms in SSIS but that wasn't possible either. You'd think with a common VM you could use any .Net language, but no.
Microsoft has always treated it as a non-mainstream language, saying "do the regular stuff in C# and use F# for the hard stuff." The problem is that C# isn't terrible for hard stuff, and if you spend most of your time using C#, then for you it's probably better.
Finally, there are many very good languages. Few are as a popular as Python...one might say even Python isn't as popular as Python, if you know what I mean...anyway, I'm not a big fan of the concept of "functional programming languages" because functional programming is a way of programming and most languages can be used imperatively or functionally and though some make it a bit easier than others most programming languages readily facilitate both. Once it was all the rage to talk about Python as a functional programming language (but making map/reduce/filter second class citizens in the past few years has hurt that story) and there are plenty of resources for functional PHP.
which brings me to my next point. the cost of switching languages is really high for most companies and often times the need to do so is driven by a direct business need (like Jet.com and their order processing engine, which ran on F# from the start).
Also, C# and to some extent Java are getting some functional-like features (type inference, anonymous functions, pattern matching), so the need to take on a new language entirely to get those features is even lower
I have no interest in F# because I don't want to work in Windows (and the dotNet platform in general).
Yes I could probably make F#/dotNet work in Linux, but at that point I have Haskell, (and SML and OCaml and Erlang). Net, net, in my dev/deploy environment, F# confers no benefit (as compared to the alternatives)
And all of it works on Linux just as well as it does on Windows.