Some personal thoughts on ReScript build

Why we should rally on a single build system in the community

In the old days of C++ era, the compiler was generally developed separate from the build system.

This is great from the technical point of view, since two systems require different skill sets, it is good to have people doing those specialized work independently.

From the product point of view, this is not great.

The large amount of work is done by the compiler, however, the user experience is defined by the build system. For any non-trivial programs, users need to use a build system to do the concurrency scheduling. Imagine the compiler author wrote a lightning fast compiler but it adopted a slow build system, the end to end user experience would still be pretty bad.

There’s more to it. For modern programming languages, people choose languages more based on the ecosystem. Having different build systems running in the wild for a language makes code sharing much more difficult. Given ReScript does not provide a stable ABI for intermediate binary artifacts like .cmj. Projects using ReScript with different build systems will be very hard to share.

There is a valid use case of a specialized build system: in house development which is not planned for OSS sharing.

What’s the current status of ReScript build

The current ReScript build used a vendored ninja to do the heavy lifting. The ninja build system is famous for being fast, I made some internal tweaks to reduce the latency to half. So I am quite happy with its performance overall.

Feature-wise, it implements most of the common feature requests, but it is not good at complex meta-programming.

Currently I am mostly responsible for the build system development and to be honest, I don’t have lots of bandwidth to improve it. Since such a piece of software is largely independent from the compiler construction, I wish there are more people involved in the build system contribution so that we can share some workload among each other.

Future directions of ReScript build

There is some interest in replacing ninja with dune for the heavy lifting. This is not the right direction. First, you will face a serious performance regression especially in the latency, an order of magnitude slowness is possible. Second, the majority of Windows users will be excluded from our community. I know some dune experts will tell me that it is possible to have dune work on Windows, but that’s not what I experienced in reality.

In the evolution of ReScript build, in the short/mid term, we may still rely on our vendored ninja for heavy lifting.

For the front-end development, we may adopt a language like Go/Rust to attract more talents to enhance the build system. Go seems an ideal choice, since it has good concurrency support and we don’t need fancy abstractions to build a robust build tool, integration with tools like esbuild would be easier. I am open to new ideas and would be happy to chat about it.


What is the front-end in this case? Are you thinking maybe an esbuild plugin that acts as the driver of the ninja build and then takes over bundling/transpiling?

When I think of good concurrency support, I usually think of clojure’s STM functionality. I haven’t used it firsthand.

rescript build or bsb is considered frontend to ninja, it generates ninja file which is consumed by it.
If the front-end is written in go, we can just vendor esbuild

My memory about STM is a bit rusty (around 10 years ago with Haskell).
It is beautiful in theory but does not deliver perf

In the meantime, Parcel 2 got rewritten in Rust (on top of SWC) :slight_smile:. Dunno if it’s any good integration-wise though.

So what’s your suggestion?
Actually I ported a small part of the build into Rust, the main issue is not which language we are going to port to, it is that who is going to commit a long time to work on it

Tbh I don’t think rewriting in rust/go or any other language would result in more community contribution.
I think we should just organize the works that should be done and write some docs to gain more contribution.