4 ms·

Hey author here, I think I failed to explain about this in the article. OCaml and ReasonML is the SAME language with different syntax. You don't need to worry

Hey author here, I think I failed to explain about this in the article. OCaml and ReasonML is the SAME language with different syntax. You don't need to worry whether the library is written in OCaml or ReasonML as long as your build tool support both ReasonML and OCaml.

kbenson 9y ago
I'm not sure you understood what my point was. I was looking at reason as a replacement solution for my current stack, and the entire stack. That includes optimized multiprocessing code, processing daemons, ORM DB access (mostly a good query builder and normalized operations), a web framework, and HTML/JS page rendering/serving (I don't really care if it's rendered at the client or server level). Right now it's 90%+ Perl, which I'm for the most part happy with, and the rest is JS, which I'm not exactly thrilled to deal with (Perl and JS are similar enough in some respects to make the parts of JS they flubbed really annoying). The main draw of ReasonML for me was the ability to have a stack of a single language that reached all the way up to the client browser and all the way down to the multi-process data retrieval and processing system. What the current status quo looks like, from an outsider, is that ReasonML is used well by people familiar with the Ocaml ecosystem to supplement and write Ocaml through a different syntax. It's also used by people familiar with Javascript to write Javascript to supplement and write Javascript through a different syntax. It works well in each of these domains, and is able to use the ecosystem of tools in each domains, but where they meet gets a little fuzzy, the packages are sparse for both domains, and there's less people already working in that space (and I'm not interested in solving problems because I'm the first in this instance). This sort of comes to a head around the webserver and/or framework. There are choices in both Javascript and Ocaml. Some of the Ocaml suggestions seemed like a good bet because I could compile the server side to mostly binaries, but how well tested are they? How well built out with features? The ones I saw seemed a bit more bare bones than I was hoping, which might be expected from an ecosystem that has been mostly compiled and focused on application and systems code. So, do I choose Node and some Javascript routing framework and helper libraries? How does that complicate any code sharing I want to do, if there's different HTTP subsystems depending on whether I'm using a JS back-end or Ocaml libraries? I also looked at doing more JS for the back-end, and just using Node to run everything. Unfortunately, Javascript libraries targeted at the system leave a lot to be desired in my opinion, and I wasn't finding much in the way of a good ORM or query builder that I thought sufficient, and a good database abstraction layer. Again, I'm finding this middle-ground to be weakly supported. I'm seeing now from replies that there are Ocaml to JS transpilers that would possibly solve some of these problems for me by pushing more of the Ocaml stack to Javascript, but I'm also not sure how I feel about committing to what might be a fragile or error prone process, or how well that interacts with other parts of the system. In summary, it really felt like there are two strong sub-communities in ReasonML, the Ocaml systems people and the Javascript/React/Web people. They both have a growing ecosystem of packages around them, but they don't necessarily play as well with each other as they could, and getting to that point will allow ReasonML to fulfill a lot of its promise. Edit: As an aside, from a sysadmin perspective, it's somewhat troubling that the bucklescript toolchain fails to install through NPM as root. Leaving aside whether it's a good idea to have it installed as root (or for that matter whether NPM should ever be run as root), it bothers me that it would fail in some unknown way on a recent RHEL/CentOS system. Failing specifically because it doesn't want to be installed as root with a notice saying as much would have been acceptable, but having a bug like that exist makes me feel like there's not enough people using the system yet to shake out the bugs. It did damage my confidence in the toolchain somewhat.

kbenson 9y ago

I'm not sure you understood what my point was. I was looking at reason as a replacement solution for my current stack, and the entire stack. That includes optimized multiprocessing code, processing daemons, ORM DB access (mostly a good query builder and normalized operations), a web framework, and HTML/JS page rendering/serving (I don't really care if it's rendered at the client or server level). Right now it's 90%+ Perl, which I'm for the most part happy with, and the rest is JS, which I'm not exactly thrilled to deal with (Perl and JS are similar enough in some respects to make the parts of JS they flubbed really annoying). The main draw of ReasonML for me was the ability to have a stack of a single language that reached all the way up to the client browser and all the way down to the multi-process data retrieval and processing system. What the current status quo looks like, from an outsider, is that ReasonML is used well by people familiar with the Ocaml ecosystem to supplement and write Ocaml through a different syntax. It's also used by people familiar with Javascript to write Javascript to supplement and write Javascript through a different syntax. It works well in each of these domains, and is able to use the ecosystem of tools in each domains, but where they meet gets a little fuzzy, the packages are sparse for both domains, and there's less people already working in that space (and I'm not interested in solving problems because I'm the first in this instance). This sort of comes to a head around the webserver and/or framework. There are choices in both Javascript and Ocaml. Some of the Ocaml suggestions seemed like a good bet because I could compile the server side to mostly binaries, but how well tested are they? How well built out with features? The ones I saw seemed a bit more bare bones than I was hoping, which might be expected from an ecosystem that has been mostly compiled and focused on application and systems code. So, do I choose Node and some Javascript routing framework and helper libraries? How does that complicate any code sharing I want to do, if there's different HTTP subsystems depending on whether I'm using a JS back-end or Ocaml libraries? I also looked at doing more JS for the back-end, and just using Node to run everything. Unfortunately, Javascript libraries targeted at the system leave a lot to be desired in my opinion, and I wasn't finding much in the way of a good ORM or query builder that I thought sufficient, and a good database abstraction layer. Again, I'm finding this middle-ground to be weakly supported. I'm seeing now from replies that there are Ocaml to JS transpilers that would possibly solve some of these problems for me by pushing more of the Ocaml stack to Javascript, but I'm also not sure how I feel about committing to what might be a fragile or error prone process, or how well that interacts with other parts of the system. In summary, it really felt like there are two strong sub-communities in ReasonML, the Ocaml systems people and the Javascript/React/Web people. They both have a growing ecosystem of packages around them, but they don't necessarily play as well with each other as they could, and getting to that point will allow ReasonML to fulfill a lot of its promise. Edit: As an aside, from a sysadmin perspective, it's somewhat troubling that the bucklescript toolchain fails to install through NPM as root. Leaving aside whether it's a good idea to have it installed as root (or for that matter whether NPM should ever be run as root), it bothers me that it would fail in some unknown way on a recent RHEL/CentOS system. Failing specifically because it doesn't want to be installed as root with a notice saying as much would have been acceptable, but having a bug like that exist makes me feel like there's not enough people using the system yet to shake out the bugs. It did damage my confidence in the toolchain somewhat.