It is interesting to note that F# took a lot of concepts from OCaml but stripped out functors, structural typing support etc. to adapt to dotnet. These adaptations are largely required because Microsoft does not treat F# as a first class citizen (at the same level as C#) and CLR is very explicitly geared towards object oriented languages. An occasional endorsement from Microsoft does not magically obliviate these deeply ingrained design decisions in F#.
Unlike ReasonML, however, typescript's type system is not sound. I have written a more detailed comparision  of TS and ReasonML. I do actively use TypeScript for my day job and mostly love it, but I am much more optimistic about ReasonML once the ecosystem matures.
My familiarity with both F# and ReasonML is quite early stage (a few weeks each) and so would welcome any corrections.
Also, to just jump in what your comment was actually about, I think the prospect of writing f# is generally a more friendly experience for those using it for the web. Or especially those using azure. Getting started with f# with ionide and vscode is literally the most pleasant onboarding I've experienced since ruby. It just goes! Amazing.
But yeah, I think reason is great too. I really like that ocaml has a centralized, external package management story. Using paket+fake isn't like a bad experience, and I mean, I wrote scala for a couple years, I can always find gratitude for a build tool of its NOT sbt, but it's awkward at times and feels like a bit more work than it should be. Of course from Microsoft's perspective, being able to jump around dotnet libs is a major boon.
You do web development primarily? I've been eyeballing TS lately, you think that's probsbly a better choice for more professional work until reasonml gets bigger pants to wear?
I do think that upcoming multicore support in OCaml is very exciting. I am more optimistic that it will attract people from Golang and C++. F# developers coming from outside dotnet is just too small a cohort.
> Getting started with f# with ionide and vscode is literally the most pleasant onboarding I've experienced since ruby.
Yeah, Ionide is really amazing. However merlin has also worked pretty well for me so far, and the emacs integration is a big plus for me. YMMV.
Also my comment was more around frontend use cases (compile to JS). I wouldn't be surprised if F# shines wrt Azure integration and within the dotnet ecosystem.
> You do web development primarily? I've been eyeballing TS lately, you think that's probsbly a better choice for more professional work until reasonml gets bigger pants to wear?
Yes, mostly node and frontend. In my area, professional work in reasonml is almost non-existent, but I do expect this to change in future.
As an developer coming from Ruby myself, glad to see more people from dynamic languages finding FP and type systems interesting.
Pfft. Run reasonml/ocaml on node, one event loop pr core, and use message passing for synchronisation / distributing work ;-)
I'm only half-joking.
The bulk of F# is functions acting on values modeled by types. This maps directly to JS. In the F# and .NET compatibility document, 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?
> 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.