I've been using ReasonML for building complex ReasonReact (React.js binding for ReasonML) apps. With the strict type system, I can code for hours without constantly looking at the browser and it just works on first try. I never feel so happy with coding like that before with Javascript. I would recommend ReasonML for all Javascript developers.
Those ReasonML has some downsides that need to be addressed:
- Bucklescript constantly releases patch version that breaks stuff, or removing deprecated functions in a minor version. I believe for a crucial piece of the ecosystem like Bucklescript, it needs to have a beta channel so we can test them before official release
- Also, there should be more communications between core team and developers, I'm scared for the longevity of the ecosystem. There are no details roadmap of what's coming next or priority of the open issues. There are many important issues (to me) that could increase ReasonML like a lot but never get addressed. An example of such issue would be shipping compiled stdlib in a separate package or have a way that would allow users to integrate ReasonML to their current node.js toolchain without waiting for building the compiler on every build (which could takes more than 3 minutes on slow CI machines)
That been said, I love ReasonML and will continue to invest in its ecosystem. Shamelessly plug, I built https://sketch.sh as a quick playground for ReasonML and OCaml, check it out if you're interested in trying ReasonML
Is lack of ad-hoc polymorphism a real issue for such projects? Everyone who used JS before are accustomed to using overridden methods, or just duck typing, which are form of ad hoc polymorphism too, but Reason/Ocaml lacks it. How does this feel? Or it's easy to code avoiding ad-hoc polymorphism after forming habit for it? Do you use things like function dictionaries to simulate ad-hoc polymorphism?
In principle it seems like a significant limitation but in practice it is rarely an issue.
ReasonML does support parametric polymorphism so it is still possible to write generic code.
Some language features conveniently help to avoid boilerplate. For example it’s possible to have a `Float` module with arithmetic operators and “open” it like this: `Float.(10.0 + 0.5 / 3.0)`.
There’s also a work in progress project called Modular Implicits that will introduce ad-hoc polymorphism.
Even then, I feel like working with Floats vs. Ints in a web browser is almost never an issue. I'd just open Float if I need it because I can't think of any scenario where I'd use both in one module
Now, you can't downcast or cross-cast or do a runtime typecheck easily, but that doesn't mean it's impossible - you just have to use roundabout ways like variants to do so (which also means that you can control which class hierarchies it is available for, and which ones it's not). A class hierarchy combined with an polymorphic variant type to allow runtime type queries can be made as powerful as a runtime typecheck/cast in Java - if more verbose - for those rare cases where you actually need it.
Of course, in practice, most cases where you'd use a downcast or a typecheck in a language like Java, map more naturally to regular variants and matching on them in OCaml.
That been said, I love ReasonML and will continue to invest in its ecosystem. Shamelessly plug, I built https://sketch.sh as a quick playground for ReasonML and OCaml, check it out if you're interested in trying ReasonML