What's the reason to use ReScript internally?

[satelllte]

Hi @nick-thompson!
I'm just wondered why after looking into it in the context of #20.
Could you please tell more about it?

[nick-thompson]

Sure! I think it's largely just a personal preference, but technically I do also take advantage of ReScript's tail-call compiler optimization.

Initially the core algorithms were written in JavaScript, and one of the common pieces of feedback I received was to provide TypeScript support, which makes good sense. As I was evaluating adopting TypeScript I found that ReScript's compiler can also output TypeScript typedefs, and actually is quite good at it. I spent a good amount of time evaluating the switch in depth, and ultimately decided to go with it: I much prefer ReScript/OCaml's type system and compiler to TypeScript, and the type inference is amazing. ReScript excels at working with recursive data structures, I also find it encourages me to write generally smarter and safer code.

There are of course some rough edges, like trying to figure out how to support unknown as we discussed in #20, but I think that's a small detail in the overall decision. And when ReScript 11 rolls out there will be some new features that will help the Elem core algorithms too (particularly unboxed variants).

Overall I'm quite happy with the decision and will soon be writing even more of the internal algorithms in ReScript

[satelllte]

Okay, I got it. Thank you for the explanation.

I actually never used ReScript, so probably I will someday to see what benifits is has.

On the other hand, I've also noticed that Elementary source keeps File.res as well as the compiled File.gen.ts next to it both committed. I'm thinking maybe this would be a good idea to generate *.gen.ts files during the CI build/compile step instead and gitignore them? This should prevent any potential human errors to make sure that ReScript vs TS files are always matched.