I've found when I do get the chance to use F# it is in .NET shops, where the tech staff have agency to make decisions. Language deciders, vs language takers. Those places typically just "choose to use it", the places I've been in generally won't advertise for it however.
IMV it thrives in back-end scenarios where correctness, and algorithmic work could occur whilst still needing some speed of development and a large enough ecosystem. It typically doesn't live in large teams hence less jobs but the teams that I've been on that use it have far reach/leverage once they are proficient at it. I've been lucky to be a part of more than one team like this.
Other languages do this too as well (Rust, Go, etc) with different tradeoffs - F#'s advantage to me is if you want easier learning of staff, correctness, interoperability, faster development IME, scripting at times and reasonable performance (e.g. C#/Java/etc class). It's rare you feel you are fighting the language or producing boilerplate or repeated code patterns; at least in the domains I've used it in. At least in my use cases it is the jack of all trades kind of language; that is its problem as well as its strength.
The push back I get is unfamiliarity and training.
Everyone is comfortable with Python. Even if in my mind, F# is great for all the same tasks, it's too big a leap.
We are spoilt with a lot of good tools these days, F# being one. As an ancedote a hybrid F#/Python shop is one use case where I have seen F# thrive. My personal view is that F# is actually better than some other langs for when you want to convert that Python code into something that runs "faster" but still looks somewhat like Python to stakeholders (I personally find F# easier to read than Python for example the generator syntax in Python to me reads backwards). This typically happens at least for me when the business team/data team/quants/actuaries/etc use Python but want you to productionise/scale it. Static typing, and lower level optimisations possible + easier access to multi-threading. I've personally converted from Python to F# models from a math background and seen 100x performance - as a bonus I can talk to the F# code and typically they understand/can read it (even if they couldn't write it directly) vs say C#/Java with a non-whitespace syntax. Allows easier verification.
In my experience having mentored devs into F# on very large projects its easier to learn F# if coming from a JS, Python, Go, etc background than C# or Java even without previous .NET exposure. Not due to a skill issue, but more of a psychological one.
IMO to be productive in F# code code tends to be simpler - many patterns that dev's valued learning in a OO context become a little obsolete or less needed as a whole. This is my anecdote but it is the C#/Java/etc crowd that tend to have the most negative immediate reaction to F# - they ask "where is X" and often I immediately say "X is bad, you shouldn't need X - think about why". They associate X with some kind of power/productivity gain, but don't realize there is many ways to do things. Kind of follows the paradigm of "frameworks/patterns are missing language features".
If they keep at it then it eventually clicks but there is almost a psychological "unlearning" that needs to be done which at least in the C# camp creates an almost tribal tension between the two camps - its just too unfamiliar. Whereas for example TS dev's seem to find it somewhat familiar in parts; even people only ever done JS previously I've found have become good F# dev's. Could be because the flow more suits the way you would code in a dynamic language while still being strongly typed (e.g. REPL's, type inference, static modules, functions over classes, etc).
Vouched for this dead comment. If this really should be flagged to death, could I get a quick refresher on what parts are boring reading or off-topic? The comment is an anecdote and not data, but this does not seem like a flamey post, or a low effort post, or a strawman post.
Probably automated. If someone creates a new account then immediately posts big comments, lots of comments, or links, the comments end up dead by default and need vouching. The dead spam comments often found at the bottom of threads are why.
As an polyglot dev who has the chance to use F# dev at times the REPL is how I POC most things - if I'm not sure of an API, even inlined into my actual codebase just hit the "Send to F# interactive" and it runs there and I can try things inside a module. Or when I want to try a new library, or when I want to do a quick benchmark, or as a substitute to a PS script, etc. You can even make F# scripts executable with the shebang `#!/usr/bin/env -S dotnet fsi` which we do a lot for scripts around our projects as an alternative to bash/python in our .NET projects where we already know a dotnet-sdk is installed. Usually runs faster too and typically just as concise. Just my anecdote opinion - the syntax and idioms of F# lean themselves more to REPL programming then C# which typically needs more OO structure rather than small code snippets strung together.
IMV it thrives in back-end scenarios where correctness, and algorithmic work could occur whilst still needing some speed of development and a large enough ecosystem. It typically doesn't live in large teams hence less jobs but the teams that I've been on that use it have far reach/leverage once they are proficient at it. I've been lucky to be a part of more than one team like this.
Other languages do this too as well (Rust, Go, etc) with different tradeoffs - F#'s advantage to me is if you want easier learning of staff, correctness, interoperability, faster development IME, scripting at times and reasonable performance (e.g. C#/Java/etc class). It's rare you feel you are fighting the language or producing boilerplate or repeated code patterns; at least in the domains I've used it in. At least in my use cases it is the jack of all trades kind of language; that is its problem as well as its strength.
reply