[sinkasapa]

I got turned off of F# because it seemed like knowing C# libraries and tooling was assumed if one wanted to do anything non-trivial, kind of like some of the functional JVM languages always assume some amount of Java knowledge and use of Java tooling. F# seemed nice, but it didn't seem like a real stand-alone language. Unlike Elm or Purescript, where one should also know JavaScript and its tooling, I don't find learning all the C# and Java stuff independently compelling enough to use F#, Scala, Frege, etc.

[FrustratedMonky]

"C# libraries"

Isn't this just .NET?

Think this was a feature. F# has access to all of the existing libraries, plus those made for F#.

[antonyt]

It's a feature but also sort of an anti-feature. To do anything productive you will need to reach for a lot of .NET libraries, and those will force you to write code differently than you would if you could live in blissful pure-F# land. This results in a mishmash of styles.

Something as simple as calling a .NET function that doesn't have F# bindings forces a change (e.g. `someLibraryFunc(arg1, arg2)` instead of `f arg1 arg2`).

This gets worse as libraries force you to instantiate objects just to call methods which could have been static, or use ref parameters, etc.

I say this as somebody who loves F# - you do absolutely have to know .NET style (which really means C# style) in addition to F# style. It's extremely pragmatic if you're already familiar with C#, but I'm not sure how wonderful it is if you come in cold.

[neonsunset]

> ref parameters

I actually like the way F# does refs more! byref<'T> aligns more closely with internal compiler terminology and makes it more clear that this is something like a pointer.

Having to perform tupled calls over curried is indeed an annoyance, and even a bigger one is the prevalent fluent style which results in

  thing
  |> _.InstanceMethod1()
  |> _.InstanceMethod2()
  |> _.Build()

Ugh, I usually try to shuffle around what I find annoying into bespoke functions (which are thankfully very easy to define) or even declaring operators. It also helps that while selection is not vast, F# tends to have various libraries that either provide alternatives or wrap existing widely adopted packages into a more functional F#-native API e.g. Oxpecker, Avalonia FuncUI, FSharp.Data, etc.

[FrustratedMonky]

" if you could live in blissful pure-F# land"

Yep. I love F# too, wish I could stay in blissful F# land.

Wish MS would just release a .NET re-done in F#? Huge task, with no payback. But would be nice.