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.
. Dunno if it’s any good integration-wise though.