4 ms·

Likely will never use again * two async models present: task (C#) & async (f#) * horrible async performance: perhaps fixed by native task & FSM transformation

Likely will never use again * two async models present: task (C#) & async (f#) * horrible async performance: perhaps fixed by native task & FSM transformation * two error handling models: Result (monadic but without do notation) & C# style Exceptions * not rich in community libraries, like a desert & abandonware

xupybd 3y ago
> not rich in community libraries, like a desert & abandonware You have access to the entire .net ecosystem?
- jasdfwef 3y ago
  They may have meant F# packages
- pjmlp 3y ago
  Right, but like the curse of guest languages (which F# isn't one), they decided to create their own ecosystem. So using .NET libraries directly is frowned upon, while some of them like GUI frameworks, expect C# features (like Roslyn and Code Generators) not available in F#.
- rami3l 3y ago
  The last time I gave F# a shot, I tried to write a simple Telegram bot in it. Just to test how much I would actually benefit from the .NET ecosystem, I chose to use a C# wrapper for the Telegram API. Suddenly I had to handle null references and exceptions everywhere (it's in this regard even worse than Rust, where I'm guaranteed to get Options and Results). I know proper support for C# T? type interop is in the works (https://github.com/dotnet/fsharp/pull/15181 https://github.com/dotnet/fsharp/pull/15181), but really it seemed to me that too few cared about F# to get it landed in a reasonable timeframe. I'd really love to see a pragmatic FP language with a reasonable amount of libs to choose from (both natively and via interop without much effort), but F# was a bit far from that description IMO.
lostmsu 3y ago
* the complexity of the compiler makes it hard to make it better
pbiggar 3y ago
Tasks are native and I've never had the use async. Performance is great. Agree that exceptions are frustrating that they exist, sadly there's little option due to C# exception model. Same thing in OCaml though less excuse over there. I basically use C# libraries directly, and it hasn't been annoying at all.

xupybd 3y ago

> not rich in community libraries, like a desert & abandonware You have access to the entire .net ecosystem?

jasdfwef 3y ago
They may have meant F# packages
pjmlp 3y ago
Right, but like the curse of guest languages (which F# isn't one), they decided to create their own ecosystem. So using .NET libraries directly is frowned upon, while some of them like GUI frameworks, expect C# features (like Roslyn and Code Generators) not available in F#.
rami3l 3y ago
The last time I gave F# a shot, I tried to write a simple Telegram bot in it. Just to test how much I would actually benefit from the .NET ecosystem, I chose to use a C# wrapper for the Telegram API. Suddenly I had to handle null references and exceptions everywhere (it's in this regard even worse than Rust, where I'm guaranteed to get Options and Results). I know proper support for C# T? type interop is in the works (https://github.com/dotnet/fsharp/pull/15181 https://github.com/dotnet/fsharp/pull/15181), but really it seemed to me that too few cared about F# to get it landed in a reasonable timeframe. I'd really love to see a pragmatic FP language with a reasonable amount of libs to choose from (both natively and via interop without much effort), but F# was a bit far from that description IMO.

lostmsu 3y ago

* the complexity of the compiler makes it hard to make it better

pbiggar 3y ago

Tasks are native and I've never had the use async. Performance is great. Agree that exceptions are frustrating that they exist, sadly there's little option due to C# exception model. Same thing in OCaml though less excuse over there. I basically use C# libraries directly, and it hasn't been annoying at all.