ML should get more love. If PolyML or MLton had received even a fraction of the support behind golang, we'd have a language with all the upsides of go (simple, concurrent, typed, etc) and none of the horrible downsides (not functional, almost zero abstraction, empty interface, no generics, pointers, etc).
ReasonML syntax just isn't as good as the ML style syntax. If I understand correctly, they started with SML then switched to Ocaml because there were more libs. I suppose it was a pragmatic decision, but I believe SML Successor would have been a much better long-term target not to mention that going with PolyML would have given them a concurrent back-end (PolyML has had years of refinement while Ocaml's implementation is still not finished yet).
Can you explain what the problem with that syntax is, is there something you couldn't express in ReasonML? It is meant to bridge the gap for existing js developers, if I understand it correctly.
Regarding the ecosystem, I think the main goal is compilation towards js and js interop, so other backends don't really matter that much, from my understanding. Maybe Ocaml just fit the bill best as a base language equivalent, regarding the features they wanted to map to and from js.
I love JS (which ReasonML tries to emulate), but the traditional ML syntax (elm, haskell, SML, etc) is simply better for me. The extra parens and curly braces everywhere don't really add anything useful to the language while complicating the syntax (well, they help solve some edge cases in Ocaml, but those cases also don't exist in most other MLs). Another result of using Ocaml is that operators aren't overloaded (not bad if you have only a couple types, but quite problematic as the number of primitive types grows). A personal annoyance is the use of JS promises (non-monadic with auto-flatmap).
Most of this applies to reason as well. http://adam.chlipala.net/mlcomp/ (I'd note that the goal of Successor ML is to add the most useful Ocaml features into SML).
As to why they chose Ocaml. More libraries makes it easier to write tooling. Ocaml has builtin tools to make writing the language much easier. Most importantly, other Facebook teams were already doing a ton of stuff in Ocaml. There are probably a bunch of other reasons, but the ReasonML guys know way more about that than I do.
Ok, yeah, I guess that's personal preference then. I have only superficial experience with traditional MLs and am currently experimenting with ReasonML, and it just feels more intuitive and productive right from the start, and context switching is easier.
With regard to operator overloading, that's the number one issue I had anytime I looked for example at haskell, it's just incredibly hard to figure out what some <=$=> operator or whatever means, and also very hard to google, so for newcomers it's really bad language UI.
Operator overloading has pros and cons. In truth, I'm inclined to agree with you that operator overload should be limited in userland, but I'm a bit incredulous at the choice with primitive data types. There are 12 or so common primitive numeric types baked into hardware. If Ocaml ever expanded to include these all, the effect without overloading would be horrendous.
Ok yes, agreed, the separate operators for different numeric types are not exactly very user-friendly either. In the de-facto use case of Reason they shouldn't be such a big deal though (building webapps).
SML overloading of builtins isn't specifically broken -- it just makes implicit assumptions about data types. That said, I'm with you about typeclasses and Ocaml's modular implicits.
If full-blown operator overloading is going to be allowed, modular implicits are definitely the way to go. If only builtin operators can be overloaded (probably a better solution in maintainable software), then a few specific typeclasses (like the current equality one) could be a more pragmatic solution.
In this particular case, I'd hedge my bets and use modular implicits, but limit them to a small list of builtin operators.
