Hacker News new | comments | show | ask | jobs | submit login

> 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

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact