> 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.