I am playing around with it. Right now I am trying to work my way through 99 problems [1], but using the ReasonML syntax [2]
I am quite far from using it professionally (or in anger, as they say), but my next toy-project/game will probably use ReasonML or ocaml.
ReasonML project tries to make most things work out of the box for particular purpose. It targets mostly frontend-devs and maybe node-js devs. I.e. I played around with buckle-script, and having it set-up on my machine was literaly just typing `npm i -g bs-platform` and adding reason-vscode extension to my visual studio code.
What I really like is the recent-is addition of esy.sh [3] that helps with compiling ReasonML trough ocaml to binary executables (previously mostly the buckle-script compilation to js worked out of the box)
Syntax is nicely familiar, type-error messages are approaching Elm-level of awesome a everything works, as long as you don't stray too much from the beaten path.
If you do stray, it can get awkward. Sometimes I didn't know if I should read documentation for reason, bucklescript or some other part of the underlying ocaml toolchain. Two examples:
First I played around with redoc [4] beautiful tool for generating documentation that contains embedded, compiled-to-js, executable code samples. But I could not compile my document, even though it looked like the example in the repo, I was getting an error about function not being present in a module.
After several hours I realize, that the example documentation was compiled with previous version of the tool, and that with lates instead just calling Module.f() I need to be calling PackageName.Module.f()
Second, I wanted to use esy.sh to work on those 99 problems. And I wanted to write tests for my solutions. I google around and find an ocaml unit-testing library [5] and it took me about an hour to figure out how to configure it. In the end it wasn't hard, it just took me quite some time to notice esy.sh is using dune [6] build system underneath and that I need to change the dune configuration files. I probably wouldn't need to do this for other libraries, but test-framework was using the ocaml extension-points (something like macro-system) and you needed to enable it in the build-config.
So far I still like it and it is not more complicated than dealing with other js-ecosystem frameworks :-) But going from node.js ecosystem to golang at work, I would preffer the go-style "just run this binary and you are fine" to js-ecosystem style "here is a rube-goldberg machine of build-systems".
I am quite far from using it professionally (or in anger, as they say), but my next toy-project/game will probably use ReasonML or ocaml.
ReasonML project tries to make most things work out of the box for particular purpose. It targets mostly frontend-devs and maybe node-js devs. I.e. I played around with buckle-script, and having it set-up on my machine was literaly just typing `npm i -g bs-platform` and adding reason-vscode extension to my visual studio code.
What I really like is the recent-is addition of esy.sh [3] that helps with compiling ReasonML trough ocaml to binary executables (previously mostly the buckle-script compilation to js worked out of the box)
Syntax is nicely familiar, type-error messages are approaching Elm-level of awesome a everything works, as long as you don't stray too much from the beaten path.
If you do stray, it can get awkward. Sometimes I didn't know if I should read documentation for reason, bucklescript or some other part of the underlying ocaml toolchain. Two examples:
First I played around with redoc [4] beautiful tool for generating documentation that contains embedded, compiled-to-js, executable code samples. But I could not compile my document, even though it looked like the example in the repo, I was getting an error about function not being present in a module.
After several hours I realize, that the example documentation was compiled with previous version of the tool, and that with lates instead just calling Module.f() I need to be calling PackageName.Module.f()
Second, I wanted to use esy.sh to work on those 99 problems. And I wanted to write tests for my solutions. I google around and find an ocaml unit-testing library [5] and it took me about an hour to figure out how to configure it. In the end it wasn't hard, it just took me quite some time to notice esy.sh is using dune [6] build system underneath and that I need to change the dune configuration files. I probably wouldn't need to do this for other libraries, but test-framework was using the ocaml extension-points (something like macro-system) and you needed to enable it in the build-config.
So far I still like it and it is not more complicated than dealing with other js-ecosystem frameworks :-) But going from node.js ecosystem to golang at work, I would preffer the go-style "just run this binary and you are fine" to js-ecosystem style "here is a rube-goldberg machine of build-systems".
[1] https://ocaml.org/learn/tutorials/99problems.html [2] https://reasonml.github.io/docs/en/overview [3] https://esy.sh/ [4] https://github.com/jaredly/redoc [5] https://github.com/janestreet/ppx_inline_test [6] https://dune.build/