Hacker News new | past | comments | ask | show | 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.

Applications are open for YC Summer 2019

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