Downsides: lack of jobs, libraries, learning materials, small community, little promotion by Microsoft outside of "what's new in F#" and other announcements.

It's a shame because F# is a beautiful language — it's fun to read, write and maintain. .NET now works well cross-platform with editors other than Visual Studio. General perks of .NET like cross-platform compilation are a nice bonus, for example, on macOS I can:

    brew install dotnet

    dotnet new console -lang F# -o HelloWorldApp

    cd HelloWorldApp

    dotnet publish -c Release -r osx-arm64 --self-contained

    dotnet publish -c Release -r osx-x64 --self-contained

    dotnet publish -c Release -r win-x64 --self-contained

    dotnet publish -c Release -r linux-x64 --self-contained

To get self-contained binaries (that don't need .NET to be installed locally) for those platforms.

There is a decent multi-platform UI framework called Avalonia: https://github.com/fsprojects/Avalonia.FuncUI

There are good actively maintained web frameworks: https://fsharp.org/guides/web/#web-frameworks

There are some passionate people writing great books about F#: https://fsharpforfunandprofit.com/ddd/

Most of F#'s adoption issues seem to be because:

1. It's tough to convince people outside of the .NET community to use .NET.

2. Most of the people using .NET use C#.

3. It's hard to convince C# users to adopt F#. (See https://www.reddit.com/r/dotnet/comments/16m0wdj/why_dont_yo... and similar threads.)

I'd love to work with F# full-time, but — short of starting my own company using it or convincing Microsoft to pay me to help them showcase its benefits — it's been hard to find work with F#, which drove me to spend time with other languages.

F# can also be compiled with NativeAOT. The main thing this target complains about is printfn and especially printfn "%A" which uses unbound reflection. So as long as you just Console.WriteLine instead it may not emit warnings:

  dotnet publish -o {folder} -p:PublishAot=true

Note that -c Release is no longer required - it is now a default for 'publish'. Also, if you are doing a self-contained/non-AOT build, you may want to do it as follows to retain compact binary size:

  dotnet publish -o {folder} -p:PublishSingleFile=true -p:PublishTrimmed=true

All the properties above can also be defined within respective .csproj/.fsproj files inside PropertyGroup blocks as e.g. <PublishAot>true</PublishAot> so you don't have to add them to a command every time.

F# also has excellent support for scripting with fsi and .fsx format: https://learn.microsoft.com/en-us/dotnet/fsharp/tools/fsharp...

Someone even made a tool for it which builds on top of bflat allowing to compile F# script files into native binaries directly without project setup: https://github.com/ieviev/fflat

Thanks for the tips! I had thought there were still some other gotchas with AOT and F# but it looks like the list is smaller than last time I looked. https://github.com/dotnet/fsharp/issues/13398

I persoanlly found the syntax weird and the IDE support poor when i was playing with it in 2013

Both of these are surprising to me. It is an indentation language, similar to Python which I love. And it was by Microsoft, which makes Visual Studio which I also loved

Yet I found the syntax a lot odder than Python: multiple ways to call methods (C# style and Ocaml style), a wide selection of strange brackets, `.[i]` for array lookup instead of `[i]` (i think they fixed this eventually). And despite Visual Studio being great for C#, its support for F# wasnt up to scratch

I ended up settling on Scala, which is semantically very similar, but with an easier syntax (not perfect, but better) and decent Intellij suppory (again, nowhere near perfext!)

The biggest difference happened between 2020 and 2024. I encourage you to give it a try - F# support with Ionide in VS Code is excellent.

There is no other platform like .NET in capability to cover both high and low level scenarios.

f# has improved a ton in the last decade. Rider and Ionide are both good environments to work on f# code in.

Since F# is primarily meant as a functional language, and thus is written as such, learning it through examples when you have no functional language knowledge, there is quite the learning curve.

Compare that to starting to read Python when you come from C#, it reads as English.

F# omits much more in its code.

You know how seasoned lisp programmers say the parentheses eventually disappear? I felt like F# was the opposite. There were invisible parentheses everywhere and once I figured out where they were, the language made a lot more sense.

Most ml based languages feel like that.

It feels like typed lisp with the brackets omitted.

But you can see that about anything with an arbitrarily complicated grammar. If you have internalized the grammar, then you can place parentheses into any utterance to show the structure, which means you can see where they would go even if you don't actually write them in.

Yes, the language make a lot more sense if you know how to do that compared to if you don't.

> anything with an arbitrarily complicated grammar

But that’s the thing about F#: the grammar isn’t arbitrarily complicated. It’s really quite simple, which is why mentally inserting lispy parentheses helps me reason about it.

Not necessarily my opinion, but here is an interview [1] about someone who gave up F# in favour of Odin ... maybe of interest here in the subthread

[1] https://odin-lang.org/news/newsletter-2024-10/#interview-wit...

I feel like going from one niche language to another even more niche language is risky, even if the performance improvement demonstrably true.

I suppose it’s a chicken and egg problem for languages that want to grow their communities (if nobody takes risks on a language it won’t see adoption) but I’m surprised given their problem domain they didn’t go with something more widely known

Not sure what's up with the author but from our brief interactions on X I have gotten an impression that they did not understand performance at a sufficiently low level and implications of using each language (and their compilers!) despite being adamant about the opposite, resulting in technical decisions driven by inaccurate conclusions. It was quite unfortunate and seemed like an emotionally-driven choice.

It's perfectly fine to use an LLVM-based language where it matters, but it's sad when C# could have been used to solve the problem without throwing the baby out with the bathwater.

Thanks to those who replied. Good info. That cross-compilation feature is cool.

The lack of jobs, that is only downside. Would use it all the time if I could, but not many companies want to switch.

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.

> (I personally find F# easier to read than Python for example the generator syntax in Python to me reads backwards).

How so? Or do you mean that about list, dict and set comprehensions?

Yes - just my preference. `[ num for num in numbers ]` in Python would read as `[ for num in numbers do num ]`. With nested loops, and if you want to do filtering (yield only on certain conditions) I felt the F# syntax reads better as the order reads top to bottom.