[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.