3 ms·

> tl;dr: The 80% best practices parity between ReasonML and modern functional javascript which the "What & Why" page of official documentation [3] talks about,

> tl;dr: The 80% best practices parity between ReasonML and modern functional javascript which the "What & Why" page of official documentation [3] talks about, does not exactly hold true for F#. The bulk of F# is functions acting on values modeled by types. This maps directly to JS. In the F# and .NET compatibility document[0], you'll note that all "core F#" components map directly to JS. And of course, you can consume JS libraries, TS definition files, etc. For example: "The following F# semantic and syntactic features are also available: * Records and Unions * Structural Equality/Comparison * Comprehensions (seq, array, list) * Computation Expressions * Pattern Matching * Active Patterns * Object Expressions * Units of measure" Do you have specific examples where F# semantics cannot map to JS such that the "80% rule" also does not hold? [0]: fable.io/docs/compatibility.html

lf-non 8y ago
I am not at all contesting the value in the good parts of F#. It was my first foray into a functional language, and I was left seriously impressed. > Do you have specific examples where F# semantics cannot map to JS such that the "80% rule" also does not hold? Yes, my comment was around some of the C# compatibility things, which don't make sense when compiling to other targets. > Tuples vs struct tuples distinction. > Having both modules and namespaces > Explicit interfaces > The strange coupling of SRTP and inlining I find OCaml's support for structural typing in classes and polymorphism to be more flexible than the above. In typed FP, runtime reflection is seldom used, and I believe reflection support (and associated overhead) should have to be explicitly opted in. I also faced weird issues when tracing the source of an exception in an async workflow, and some incomprehensible errors around automatic generalization. But this was a long time back and I no longer have the full context. These may have since been addressed. My intent was certainly not to criticise F#. It has been developed and is used by people far smarter than me. It is just that after a preliminary evaluation I have not found a strong reason to prefer Fable over bucklescript in the absence of a more deeper commitment to dotnet stack. I am also really fond of many modern JS features like Module <-> Filepath 1:1 correlation, explicit imports, ES6 proxies, tagged template literals (placeholders etc.) which TypeScript elegantly inherits from JS. Support for intersection types in typescrpt is also very handy.

lf-non 8y ago

I am not at all contesting the value in the good parts of F#. It was my first foray into a functional language, and I was left seriously impressed. > Do you have specific examples where F# semantics cannot map to JS such that the "80% rule" also does not hold? Yes, my comment was around some of the C# compatibility things, which don't make sense when compiling to other targets. > Tuples vs struct tuples distinction. > Having both modules and namespaces > Explicit interfaces > The strange coupling of SRTP and inlining I find OCaml's support for structural typing in classes and polymorphism to be more flexible than the above. In typed FP, runtime reflection is seldom used, and I believe reflection support (and associated overhead) should have to be explicitly opted in. I also faced weird issues when tracing the source of an exception in an async workflow, and some incomprehensible errors around automatic generalization. But this was a long time back and I no longer have the full context. These may have since been addressed. My intent was certainly not to criticise F#. It has been developed and is used by people far smarter than me. It is just that after a preliminary evaluation I have not found a strong reason to prefer Fable over bucklescript in the absence of a more deeper commitment to dotnet stack. I am also really fond of many modern JS features like Module <-> Filepath 1:1 correlation, explicit imports, ES6 proxies, tagged template literals (placeholders etc.) which TypeScript elegantly inherits from JS. Support for intersection types in typescrpt is also very handy.