When does ReScript make sense at work?

As someone who loves ReScript, the question of whether or not I’d ever dare suggest that it should be used at work is something I’ve thought about a lot. Many trade offs to consider are items to weigh when introducing new tech in general, but the consequences of introducing a new language are amplified compared to something like a library. The topic is complex, and I’ll miss many things to consider, but even a limited exploration is worthwhile.

For starters, we have to properly understand the ultimate goods that we are trying to achieve which isn’t a language that aligns with a certain paradigm, or that has certain features. While paradigms and features create good outcomes, they are not the end in and of themselves. What actually matters is how a language enables a team to create a better product. A language that allows teams to build a better product allows teams to do things like move fast, make safe changes (without breaking things), have good access to libraries, allow many developers to work on the same code even as key team members come and go. (These aren’t just important for languages, they’re goods that we strive for when picking many tools, libraries, etc).

First we’ll look at potential problems when trying to adopt ReScript and then the benefits.

Problems with adopting ReScript

How does ReScript fit here? Maybe we start with the obvious down sides — the biggest of which is a small community and few developers that know the language. This opens a whole host of hurdles that your company is likely to face.

Staffing Issues
Staffing is a first problem. Some argue that adopting compile to JS languages solves staffing needs because there’s often a community of ready developers who have few opportunities to use a language they’re passionate about (in this case ReScript). I’m skeptical of this, and I’m unaware of data that strongly supports the claim. The opposite is just as likely (and seems more plausible) which is that you’ll struggle to find local ReScript developers in your area.

Suppose you’re not able to find ReScript developers so you instead decide to just train new developers to use ReScript. I foresee other issues here as well. The first is that developers looking for jobs are largely interested in building their careers. Putting ReScript on their resume in the current market is likely perceived as less beneficial than TypeScript. In other words, developers are incentivized by TypeScript/JavaScript marketability to establish their expertise in TS/JS, not ReScript. It’s easy to imagine a scenario where you end up with a developer or two who are passionate about the language, and the rest accepted your ReScript job offer because they couldn’t land the TypeScript roles.

Finally, you have to convince almost everyone on your current team that ReScript is a good idea, and that it won’t make them miserable when they have to learn it. (As someone that loves ReScript, it’s tempting to believe that others would share my enthusiasm if they only tried it, but deep down we know that’s not the case). For reasons already mentioned, the chances of all or even most developers being excited about having to use a new language to do their job is unlikely and you might even lose good developers if they don’t have an option to go to another project that doesn’t use ReScript. You’ll also get to hear people blame the language and the decision to use it for failures in the project.

JS Ecosystem is available but you have to write bindings
Good news, the JS ecosystem is available for your team. Bad news, your team has to write bindings for many dependencies, and has to do so with care and integrity. While some important libraries already have bindings available, many do not. Even then, the bindings package may not be well maintained and the future of many packages is dubitable. When it comes to delivering features safely and quickly, writing your own bindings is an issue. In other words, the bindings aspect of ReScript comes with a speed and safety cost, and also means your team has bindings to maintain in addition to their production code.

On top of all this, some JS libraries simply don’t translate well to ReScript. ReScript’s type system is much stricter than TypeScript’s. Without the extremely flexible, sometimes unsound, type system that TypeScript offers, some aspects of the JS ecosystem might still be available only in a limited manner.

A limited ReScript ecosystem
The ReScript ecosystem is still young. While there are some great tools developed for ReScript, the ecosystem is small. Most of your dependencies you’ll have access to through bindings.

Reasons to Adopt ReScript

At this point, you might already feel like ReScript is absolutely the wrong decision for your production code. The down sides we looked at are pretty large barriers, but the benefits are pretty good too.

I’d argue that if you can manage to get a competent team of ReScript developers, it improves most of what makes a code base suitable for developing great products.

I sincerely believe you can:

1. Achieve a greater degree of safety
2. You can make changes faster
3. Create space where many developers can work (once they know the language)

The right type system
The ReScript programming language has an excellent type system. For starters, the type system is sound. This means that you have less need to worry about developers lying to the compiler — this can still be an issue, but it will generally stem from bad JS bindings or mistyping an API response. You won’t need to worry about developers writing buggy code because they’ve added anys or because some important feature returns any (like Object.values in TypeScript).

The type system also absorbs other kinds of problems. Instead of using null in ReScript, developers use option. I won’t explain too much more about option, but it forces developers to explicitly deal with values that are possible missing. While exceptions exist in ReScript, ReScript also uses the result type for much of its error handling which most ReScript developers prefer. The result type makes it hard for errors to go unaccounted for in your app.

Both the option and result type have significant advantages when trying to work with someone else’s code and trying to make changes safely and quickly. If there’s some potential problem, whether the value be null or a function is fallible, the ReScript type system forces you to deal with it.

Less JavaScript weirdness
JavaScript is notorious for weird syntax and rules. While you still have to deal with JS since ReScript compiles to and interops with JS, many problems with JS either go away or are less of an issue. Almost all thoughts about what is “truthy” and “falsy” go away which is a blessing. The option type means that you only need to think about null and undefined when you have to interop with JS. In short, ReScript hides much of the baggage JS brings.

Functional features
ReScript is a language born out of OCaml. While you can comfortably write the language in an imperative manner, its functional features help promote good coding habits that make for safer code.

One of the most disappointing parts of working with TypeScript is that values are mutable by default. In ReScript, values are immutable by default, but can become mutable if you explicitly make them so.

Working with varying kinds of data is also well supported ReScript. Variants and polymorphic variants play with the language’s pattern matching feature. Similar behavior can be achieved in TypeScript, but it feels clunky and cluttered. ReScript’s variants and exhaustive matching are simpler and more obvious than TypeScript’s discriminated unions.

These features matter quite a bit when creating projects that are intended to be maintained/iterated on quickly for years to come.

All in all, I have a huge amount of confidence in ReScript, but I don’t think I have the guts to suggest that we should switch to the language at work quite yet. For really complicated projects with few dependencies, I’d be inclined to suggest it for a green field project.

I sometimes imagine which technologies I’d rely on when it really needs to work, and ReScript wins over JS every time. If hypothetically there is a critical piece of front end web technology hooked to equipment my surgeon is using, I’d sure rather it be written completely in ReScript than TypeScript or JavaScript.