6 ms·

>At any rate, F# is a terrific language. Any downsides, in your opinion? I had toyed with it a few years ago, using that lightweight IDE called LINQPad, IIRC,

>At any rate, F# is a terrific language. 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/ https://www.linqpad.net/

modernerd 2y ago
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 https://github.com/fsprojects/Avalonia.FuncUI There are good actively maintained web frameworks: https://fsharp.org/guides/web/#web-frameworks https://fsharp.org/guides/web/#web-frameworks There are some passionate people writing great books about F#: https://fsharpforfunandprofit.com/ddd/ 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_you_just_use_f/ 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.
- neonsunset 2y ago
  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-interactive/ 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 https://github.com/ieviev/fflat
  - modernerd 2y ago
    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 https://github.com/dotnet/fsharp/issues/13398
lihaoyi 2y ago
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!)
- neonsunset 2y ago
  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.
- runevault 2y ago
  f# has improved a ton in the last decade. Rider and Ionide are both good environments to work on f# code in.
smartmic 2y ago
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-with-crews https://odin-lang.org/news/newsletter-2024-10/#interview-wit...
- neonsunset 2y ago
  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.
- no_wizard 2y ago
  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
OptionOfT 2y ago
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.
- sevensor 2y ago
  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.
  - UK-Al05 2y ago
    Most ml based languages feel like that. It feels like typed lisp with the brackets omitted.
  - kazinator 2y ago
    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.
    - sevensor 2y ago
      > 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.
fuzztester 2y ago
Thanks to those who replied. Good info. That cross-compilation feature is cool.
FrustratedMonky 2y ago
The lack of jobs, that is only downside. Would use it all the time if I could, but not many companies want to switch.
- throwaway675867 2y ago
  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.
  - FrustratedMonky 2y ago
    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.
    - throwaway675867 2y ago
      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.

modernerd 2y ago

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 https://github.com/fsprojects/Avalonia.FuncUI There are good actively maintained web frameworks: https://fsharp.org/guides/web/#web-frameworks https://fsharp.org/guides/web/#web-frameworks There are some passionate people writing great books about F#: https://fsharpforfunandprofit.com/ddd/ 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_you_just_use_f/ 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.

neonsunset 2y ago
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-interactive/ 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 https://github.com/ieviev/fflat
- modernerd 2y ago
  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 https://github.com/dotnet/fsharp/issues/13398

lihaoyi 2y ago

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!)

neonsunset 2y ago
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.
runevault 2y ago
f# has improved a ton in the last decade. Rider and Ionide are both good environments to work on f# code in.

smartmic 2y ago

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-with-crews https://odin-lang.org/news/newsletter-2024-10/#interview-wit...

neonsunset 2y ago
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.
no_wizard 2y ago
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

OptionOfT 2y ago

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.

sevensor 2y ago
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.
- UK-Al05 2y ago
  Most ml based languages feel like that. It feels like typed lisp with the brackets omitted.
- kazinator 2y ago
  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.
  - sevensor 2y ago
    > 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.

fuzztester 2y ago

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

FrustratedMonky 2y ago

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

throwaway675867 2y ago
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.
- FrustratedMonky 2y ago
  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.
  - throwaway675867 2y ago
    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.