Here is my experience of 5h with reasonml. It is only my developer experience, and I focused on the things that can be improved.
- didn't hit any bugs
- type inference is really pleasurable
- merlin worked great in vscode
- awesome discord community
- a tutorial to build a basic stuff with list and records
- JSON.stringify
- examples with unit tests in the doc
- less repos, less tools, more consolidated experience
- List.map really helped me moving fwd and gaining in velocity. It is not ocaml-style, but it is FP nonetheless.
- I didn't understand that the List in reason is a List in ocaml. The doc was suggesting it was its own type?
- I needed way more list examples. Finally found the unit tests, which helped, but they are not really UT in the sense that they only test correct translation to ocaml. To understand what a couple of operations do, I had to fallback to ocaml quite fast
- I ended up copy and pasting full examples from stackoverflow from ocaml to get started. Translation was not difficult nor easy
- The examples in the html doc don't print results, how do I check you perform the right result?
- lack of built in serialization was almost a showstopper. The first thing I try to do is to look at my structures to check its results. But even this check becomes an exercise in itself, and if I did a mistake for instance in my list manipulation, i would do the same in my tooling to figure out what is going on. So I would have a broken code that I cannot debug.
- didn't understand why I had to upgrade a formatter (fmt) to get a pretty printer/serializer.
- couldn't figure out if I used pp/fmt or ... when using bsb as presented in the JsWorkflow section of the docs. So I didn't know where to put the flags.
- Despite the help of the ppl on discord, I couldn't successfully upgrade fmt to get show_tree running on mac osx, so I gave up.
- was offput by the idea of installing as npm globals. How can I clean my env easily if I don't like reason? If I love it, how do I ensure having different projects with different versions of the packages?
- 30 repos! names are not explicit. It was a lot to ask to go through the 30 to figure out which ones were relevant, especially with funky names like reductive or nopam or fastrealpath or ninja or ... I'm from a web background.
- Didn't understand at first that reasonml repo was not part of reasonml group. I opened 15 of the mysterious github reasonml/ repos before figuring that out.
- I had to refer a lot to the ocaml doc for the APIs, which I'm okay with, but it makes another syntax to digest upfront.
- Errors are not always explicit, as they sometimes use vocabulary that is not mentioned in the reason docs.
- I had to read again the ocaml docs, which suggested me to install ocaml, which started to create a mess in reasonml install.
- As expected, as ocaml is a language used quite a lot in schools, we find a lot of people asking questions, and a lot of smart dudes only providing hints to let the readers do the exercises themselves. Therefore, looking for the correct syntax / API on stackoverflow was less of a pleasurable experience compared to JS/PHP/HTML/CSS/SQL/Typescript/Flow. I can have way more fun in coding than trying to figure out what is an acceptable syntax or what is the correct API for list for instance.
- having no listing of available modules (Hashtbl, List ...) I assumed after the above experiences, it would be complicated to use them, but it was quite simple overall ( I typed map by mistake and saw a signature in my IDE).
- don't understand the role of the expression "open something" as it works without it as long as I type something like "module".member
- semicolons - had difficulties putting them back after standard js, but hey, its life.
- context switching between js, ocaml, reason takes a toll on my focus. It is prob. just me.
- didn't understand how to derive a type from an existing one. I tried to do a simple algorithm which progressively enriches with new fields various records. Ended up creating a bunch of mutable fields 'cause creating all the types for the intermediary representations seemed like a big waste (10 steps, 10 different types). And it would have forced me to reimplement all the printing functions...
- having to switch between a build process and my script feels like a step backward compared to modern webpack experience which displays in big red the problem and re-execute the code if everything is okay. Would be cool to give an entry point / main file to get re-executed by the watcher when everything is okay, so I would have only one term to monitor
- I wished there was an online editor to test and hack snippets shared by the members. Or just for my quickstart, to convince me that it works before starting to install globally some pkg.