I had toyed with it a few years ago, using that lightweight IDE called LINQPad, IIRC, but did not follow up, or keep track of its pros and cons or progress later.
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:
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:
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.
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
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.
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.
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.
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!)
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.
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.
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.
Any downsides, in your opinion?
I had toyed with it a few years ago, using that lightweight IDE called LINQPad, IIRC, but did not follow up, or keep track of its pros and cons or progress later.
https://www.linqpad.net/