For the “split” with Rely, I think you’re seeing a couple of things:
- Syntax is more important than you initially would expect because it even influences the kinds of APIs that would be more readable. Rely’s API is designed to have a callback as the final argument, and the community has even built special formatting for this use case - and this matches what the JS community is used to with Jest and Prettier.
- Reason appeals to the JS community even when it is supporting the native toolchains. So some of the libraries we’ve developed and released for native, appeal to a different audience than existing OCaml programmers. The existing libraries and testing frameworks in the OCaml ecosystem are great. But by making everything as familiar as possible within the Reason libraries and toolchains, it acts as a way to get more people exposed to the language, because the JS ecosystem is where all the developers are. (I would recommend making things as frictionless and superficially familiar as possible - but not to the extent that the technology is worse of course).
Console does something different than the
logs library you mentioned. Console is designed to be equivalent to the
console.log of node/browsers, and is totally polymorphic, requiring no ceremony or static typing. It’s really just for log debugging. But again, it is designed to be immediately familiar to the largest number of developers - and coming from the JS community.
esy: Like the others,
esy is designed to be immediately usable by the largest number of developers (and they happen to come from the JS community). It’s true that we need to make it installable from places other than npm, and it would be great to get more people from the OCaml community to check it out and contribute. Many have already contributed feedback or fixes!
One thing that we could and should do better, is release more of the packages we’ve made with esy, onto the opam repository (once we’ve tested them sufficiently). We’ve made some progress here, and I’ve created some build steps that automatically generate opam files in the reason-native libraries.
My original assumption was that developers in the OCaml ecosystem were content with the opam workflow (especially since it does so many great things with CI and its testing matrix). Npm developers have a higher expectation of project isolation. But I have been pleasantly surprised that many OCaml programmers have appreciated esy as well. Some of the projects you see on Github might have opam packages, but their contributors might still be using esy because esy can build opam projects too.
Docs is one place where the difference is not intentional - we just need a little more help. For example, is anyone willing to help rebuild the OCaml manual/standard library in Reason syntax? That would be helpful - please get in touch if anyone’s interested. (It’s an automated process that is generated via a build - but we need to inject the reason parser/top level into it).
Having separate Discourse/Discord has some benefits in that Reason has a lot of newcomers to the language, and a lot of them have large overlap with the compile-to-js workflow (BuckleScript). There are a lot of cross-discussions across the different Discord servers though.
esy, I would also like to point out one amazing tool built by someone in the Reason community that integrates well with both Reason and OCaml: sketch.sh.
I think if you dig a little deeper, you’ll come to the realization that the Reason ecosystem in the native world, is actually not so far diverged from the OCaml native ecosystem on all the important parts. Andrey Popp (architect of esy) went to great lengths to make esy support opam packages for example. Dune works with Reason (as mentioned by others). For everything else that seems like an unnecessary difference, I think it’s best to ask whether or not that difference accomplishes the goal of appealing to a wider audience(which means JS) without compromising on quality. If the answer is “no it doesn’t help with wider reach”, then we should probably revisit some things and do a better job of integrating with the OCaml ecosystem. If the answer is “yes”, I’d say it’s worth it - but that’s just me.