- A cross-platform native-compiling GUI library with a React-influenced design: https://github.com/revery-ui/revery
- A lightning-fast Node version manager: https://github.com/Schniz/fnm
- Erlang-like multicore actors: https://github.com/ostera/reactor
That said, it's early days and the ecosystem has to (and will) mature a lot.
Is the implication that plain OCaml is not good?
The esy package manager alone is a huge improvement over opam and npm.
All that said, the OCaml tooling is definitely making strides in the right direction. Dune for one thing is incredible and we are lucky to have it. I'm just saying there is room to make things easier for developers, and Reason is also moving that forward.
- Having to learn how to use let ... in
- Having to learn how to use semi-colons and where and why
- Having to enclose `else` clauses in parentheses or begin/end keywords and learning why they are necessary
- Having to use multiple pairs of parentheses to enclose function arguments like `foo (a + b) (c - d)`. With Reason it's `foo(a + b, c - d)`. And another bonus, function application in Reason actually looks like high school math function application
- Having to learn to distinguish between tuples and multiple arguments in data constructors
Those are just off the top of my head. In addition, ReasonML's refmt tool lets you avoid bikeshedding discussions about code formatting–it's a whole-program formatter. And some additional syntax niceties like single-@-symbol annotations and the upcoming single-line comments (//)–something OCaml will most likely never get.
Especially with nested expressions, the inability to find mismatched parens and braces ultimately turned my team's experiment with it sour.
The base language's grammar is said to have inconsistencies, but I think Reason's 1:1 matching while keeping older constructs makes translating very difficult. There is a tool to do so, but it's lossy.
That said, I use Reason React for a small front end project at work and sort of wish that the ppx for JSX wasn't tied to Reason, so that vanilla OCaml could be used instead.
An example of lossy translation from Reason -> OCaml:
https://reasonml.github.io/en/try?rrjsx=true&reason=DYUwLgBA...
Doesn't it allow to quickly code something like HyperScript-Helpers?
the explicit_arity being added in. I can't think of other examples at the moment.
Maybe lossy is the wrong word, but the transforms historically had gotchas. PPX and what not. Especially when converting between Reason syntax version upgrades and the more stable OCaml syntax (locked to OCaml 4.2 because of bucklescript).
That doesn't necessarily mean lossy, but just that knowing what refmt will error out on depending on the version of Reason the code was written to target vs. locked down ML.