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 ha

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.