How popular is Reason Native?

#1

Since I first set foot in the land of native Reason dev, a bit more than a year ago, it would seem that the community and authors’ focus has been even less on Reason-as-Ocaml syntax, and more, if that’s even possible, on Javascript.

I would like to know what future the smart folks behind the language are envisioning.
I just spent a few days reviving my original project, converting it to work with OCaml 4.09, and again found that this is definitely the path less traveled. I had to resolve every issue by myself.

I plan on creating a new post delineating every step I took to update the project, including adding tests, finding out what does and doesn’t work debugging-wise, and building gotchas.

Am I correct to infer that the native community is minuscule, or is it simply the quietest community ever?

#2

What difficulties did you face? It could be that the community is small, but we see increasing interest in native compilation. Then again, it could depend on who you ask.

Also, are you on Discord? There is #native-development channel on Reason server where quite a few native development chatter happens.

#3

I for one am very interested in Native Reason! In fact I am working on a fullstack Reason … stack. And I think there’s a lot of interest from a wider circle and activity from a smaller but capable circle of people. There are a few caveats though. It would be good to know exactly what issues you faced because from what you described so far:

These issues could have come from the native OCaml tooling or from Reason tooling. We’ll need more details to figure that out :slight_smile:

#4

It is possible, indeed, that many of the wounds were self inflicted :wink:

For instance, the popularity of esy has, ironically, made my life more difficult. Now I have to deal with two package managers: opam and esy. And it looks like I need to install every package twice.

Your comment about OCaml is particularly salient: while Reason was updated to work with OCaml 4.09, it appears that many OCaml packages were not updated and need modifying before the compiler accepts them (unused variable warnings handled as error make for very short compile time, if you know what I mean)

I also found out that, when building + installing an OCaml package, I still need to manually link its stubs to, for instance, /usr/local/lib/, as dune does not look for them under ~/.opam/default/

OCaml again: until I pinned every single dependency, my build was rife with incompatibilities.

I then had to figure out how to install @reason-native/rely, for instance, without using esy (I ended up git-cloning, building and installing, using the .install files)

There is also, to my knowledge, a lack of user-friendly debugging tools: red had to be patched because, ironically, its Python syntax had become stale. I was, however, able to use ocamldebug once I had modified LD_LIBRARY_PATH and realized that Dune mangles all entity names. A couple IDE-friendly tools exist, but they are not compatible with 4.09.

#5

That is indeed ironic. Esy is a quite promising superset of opam that gets a lot of things right. But I find that OCamlers are quite … attached … to opam. I haven’t seen the level of care for build reproducibility that I would need in a project. I’ve often come back to an opam switch after a few months away and it’s been … totally borked.

#6

You could ask all the native tooling questions on https://discuss.ocaml.org/ to get more answers.

Don’t use the default opam switch, i.e. the ocaml installed on your computer by your package manager. It results in a big mess and everything tend to be broken.

opam pin add rely https://github.com/facebookexperimental/reason-native.git

To be fair, esy UI is far from good, the solver has been broken for some time, it doesn’t support all packages by default, it doesn’t support using multiple opam repositories, it was advertised in a very bad way with flawed arguments (such as “it downloads packages in parallel”). I like esy, but there is quite some work to do before it gets adopted by everyone.

#7

esy’s opam compatibility is a work in progress. Solver has been broken but not unfixable to my knowledge.

it was advertised in a very bad way with flawed arguments (such as “it downloads packages in parallel”)

Would you like to elaborate? @Khady

#8

I agree that Esy still needs more work to get into a polished state but I don’t recall seeing any ‘bad’ advertising. As Manas said, perhaps you would like to clarify and source that assertion. The only mention of ‘parallel’ I can see is on https://esy.sh/docs/en/what-why.html#for-opam-https-opamocamlorg-users

Fast parallel builds which are aggressively cached (even across different projects).

Which seems correct to me.

I do feel that it gets the basics (reproducible builds, lockfiles, cached packages) exactly right. Without those it’s difficult to take a package manager seriously nowadays :slight_smile:

#9

The solver was fixed, at least enough to sustain my personal use cases. Compatibility is globally good. And I can only thank the people who take time to populate the esy overlay to fix compatibility of broken packages. None of the issues I described are horrible. They are for sure fixable. I discussed a few times with Andrey or other esy contributors about the support of multiple opam repo, which doesn’t seem hard to do be no one had the motivation to do it. I am the first one to blame for not working on it.

My point was definitely not to say that esy is bad or shouldn’t be used. Just that if people are not switching to esy it’s not only because they are lazy and attached to an old workflow.

I’m not sure it’s very interesting as it was already a few years ago. But the example of the parallel downloads is something Jordan told me again and again when I ask on discord why esy was better than opam. While I believe the fact that it composes a small set of packages to make minimal environment to build a new package is actually much more interesting. The lockfiles are also more interesting. The fact that the cache can be relocated is not just a hack made up by esy authors, it is something which already works in nix.

All this was a long time ago and we can’t change the past. Nowadays I believe that the strength of esy are recognised by enough powerful members of the community. It just took longer than expected. Hopefully enough work will go into esy to make it a great tool which will naturally take over opam. Or maybe the great ideas of esy will go into opam. I don’t really care :slight_smile:

Manas asked me to elaborate, not to justify myself. That’s less aggressive :slight_smile: You can dig discord or twitter if you want to find the old discussion that you don’t recall.

Definitely. But if it can’t install my packages, all those nice features are of no use.

#10

At the end of the day, this is the curse of writing a package manager: as a critical tool used constantly by devs, it needs to be of superior quality than most software.
IMHO, the people working on it must be crazier than average, since they are also subjecting themselves to the craziness of the upstream library ecosystem, where one of the most important keywords is conflicts!

#11

Manas asked me to elaborate, not to justify myself.

That’s true. Didn’t mean to twist his words . Sorry Manas.

However…

That’s less aggressive :slight_smile:

True, I do tend to respond a bit more aggressively if I perceive that something aggressive is being said, like ‘bad advertising’. I should try to de-escalate in future.

You can dig discord or twitter if you want to find the old discussion that you don’t recall.

Well I went digging in Discord and I honestly don’t know what you’re referring to. Every time I see Jordan talking about ‘esy’ and ‘parallel’, it’s about parallel builds. It’s never about parallel downloads. So I still don’t agree that there was any misrepresentation :slight_smile: