4 ms·

F# code can certainly be written in C# style (no DU's, use nulls instead of option types, mutables, etc.) and should not differ much from the C# IL. Seems like

F# code can certainly be written in C# style (no DU's, use nulls instead of option types, mutables, etc.) and should not differ much from the C# IL. Seems like doing this on the hot-path (or re-write a few fn's in C#) should be enough -- why did you need to ditch re-write the whole project? EDIT: Just saw your reply. I do agree about the IDE -- having ReSharper, OzCode, etc., on my side is a great advantage on the C# side, even though I'm an F# fan as well. Also at this point C# is a fine FP programming language itself. (Can 8.0 finally pattern-match tuples sanely?) The only thing missing are DU/sum-types.

platz 7y ago
unfortunately C# pattern matching is really only a glorified switch with destructuring that doesn't provide any level of exhaustiveness checking that is very helpful in maintaining code under conditions of change.
- thelazydogsback 7y ago
  Agreed. Even w/o DU's/sum-types/case-classes, there could be a compiler option when matching an instance against a lists of sub-classes that a warning/error is generated if the list of sub-classes does not fully cover the parent class. (It should be fairly easy to write a Rosyln-based plug-in that enforces this.) Typescript allows you to express this kind of thing pretty well -- maybe some of that work will end up migrating to C#. F# used to be the C# feature playground, but that's probably changing now. Not sure if TypeProviders will ever make it...
  - platz 7y ago
    TP's I don't think have quite borne out the usefullness-to-complexity ratio
    - thelazydogsback 7y ago
      Agreed, but anything is better than some 3rd-party tool (that may or may not be integrated into the build) doing one-off ad-hoc code generation. I think any C# meta-programming facility would be a good step. Certainly the TP interface(s) could be simplified for C#.
      - platz 7y ago
        well there are T4 templates for C# code-gen, although I can't say I've ever been eager to use them.

platz 7y ago

unfortunately C# pattern matching is really only a glorified switch with destructuring that doesn't provide any level of exhaustiveness checking that is very helpful in maintaining code under conditions of change.

thelazydogsback 7y ago
Agreed. Even w/o DU's/sum-types/case-classes, there could be a compiler option when matching an instance against a lists of sub-classes that a warning/error is generated if the list of sub-classes does not fully cover the parent class. (It should be fairly easy to write a Rosyln-based plug-in that enforces this.) Typescript allows you to express this kind of thing pretty well -- maybe some of that work will end up migrating to C#. F# used to be the C# feature playground, but that's probably changing now. Not sure if TypeProviders will ever make it...
- platz 7y ago
  TP's I don't think have quite borne out the usefullness-to-complexity ratio
  - thelazydogsback 7y ago
    Agreed, but anything is better than some 3rd-party tool (that may or may not be integrated into the build) doing one-off ad-hoc code generation. I think any C# meta-programming facility would be a good step. Certainly the TP interface(s) could be simplified for C#.
    - platz 7y ago
      well there are T4 templates for C# code-gen, although I can't say I've ever been eager to use them.