4 ms·

+1 F# is criminally under-used

throw954387543 1y ago
I've used it, and am still using it, to generate lots of value in a very large org. Having a language where I can bring Go, Node, etc developers over and get relatively better performance without having to teach OOP and all the implicit conventions that are on the C# side is a bit like a cheat code. With modern .NET, its better than Java perf, with better GC, and having the ability to code generic Python/JS looking code whilst still having type checking (HM inference). There are C# libraries we do use but with standard templates for those few with patterns to interface to mostly F# layers you can get very far in a style of code more fitting of a higher more dynamic language. Ease of use vs perf, its kind of in the middle - and it has also benefited from C# features (e.g. spans recently) Its not one feature with F# IMO, its little things that add up which generally is the reason it is hard to convince someone to use it. To the point when the developers (under my directive) had to write two products in C# they argued with me to switch back.
lostmsu 1y ago
I used it for many years but ended up switching to C#. The language needs better refactoring tools. And for that it needs something like Roslyn. The existing compiler library is too slow.
- munchler 1y ago
  That would be nice, but refactoring canonical F# is still far easier than C# due to its referential transparency. https://dev.to/ruizb/function-purity-and-referential-transparency-7h1 https://dev.to/ruizb/function-purity-and-referential-transpa...
  - lostmsu 1y ago
    No, it is not. Referential transparency <<< tooling. Plus F# as a functional language has significant gaps that prevent effective refactoring, such as lack of support for named arguments to curried functions.
    - munchler 1y ago
      Can you give me an example where lack of support for named arguments to curried functions makes refactoring difficult? I'm having trouble understanding how that would happen.
      - lostmsu 1y ago
        For one there's no way to add a curried parameter without doThing4-style naming and lack of named arguments implies you can't have a default value for the new parameter. Another one is if you want to add a curried parameter to the end of the parameter list, and you have code like |> myFunc a b |> ... You can't just say |> myFunc a b z=10 |> ... instead, you have to rewrite the whole pipe.
        munchler 1y ago
        OK, I think I see what you mean. I certainly agree that named arguments with default values can be useful, but are not supported by curried functions.

I've used it, and am still using it, to generate lots of value in a very large org. Having a language where I can bring Go, Node, etc developers over and get relatively better performance without having to teach OOP and all the implicit conventions that are on the C# side is a bit like a cheat code. With modern .NET, its better than Java perf, with better GC, and having the ability to code generic Python/JS looking code whilst still having type checking (HM inference). There are C# libraries we do use but with standard templates for those few with patterns to interface to mostly F# layers you can get very far in a style of code more fitting of a higher more dynamic language. Ease of use vs perf, its kind of in the middle - and it has also benefited from C# features (e.g. spans recently) Its not one feature with F# IMO, its little things that add up which generally is the reason it is hard to convince someone to use it. To the point when the developers (under my directive) had to write two products in C# they argued with me to switch back.

lostmsu 1y ago

I used it for many years but ended up switching to C#. The language needs better refactoring tools. And for that it needs something like Roslyn. The existing compiler library is too slow.

munchler 1y ago
That would be nice, but refactoring canonical F# is still far easier than C# due to its referential transparency. https://dev.to/ruizb/function-purity-and-referential-transparency-7h1 https://dev.to/ruizb/function-purity-and-referential-transpa...
- lostmsu 1y ago
  No, it is not. Referential transparency <<< tooling. Plus F# as a functional language has significant gaps that prevent effective refactoring, such as lack of support for named arguments to curried functions.
  - munchler 1y ago
    Can you give me an example where lack of support for named arguments to curried functions makes refactoring difficult? I'm having trouble understanding how that would happen.
    - lostmsu 1y ago
      For one there's no way to add a curried parameter without doThing4-style naming and lack of named arguments implies you can't have a default value for the new parameter. Another one is if you want to add a curried parameter to the end of the parameter list, and you have code like |> myFunc a b |> ... You can't just say |> myFunc a b z=10 |> ... instead, you have to rewrite the whole pipe.
      - munchler 1y ago
        OK, I think I see what you mean. I certainly agree that named arguments with default values can be useful, but are not supported by curried functions.