title: Ripple # A build system for the next decade Ripple is an experimental build system. Blending functional reactive programming, process tracing, automatic memoization, and a smattering of object capabilities, it aims to completely redefine the state of the art in software assembly. Ripple will provide completely [reproducible builds](https://reproducible-builds.org/), guaranteeing that any piece of software which builds successfully on one computer can be recreated bit-for-bit identically on any other computer — even ten years down the line. This allows users of binary packages to be confident that they're running software directly corresponding to published source code. While reproducible builds are nothing new, combining them with automatic fine-grained incremental compilation is necessary to make them usable every step of the way, as opposed to something only performed at software release time. By doing so, Ripple will banish invocations of `make clean` to antiquity, and save billions of hours of CPU time wasted by CI systems pointlessly rebuilding the same thing over and over again. In addition, Ripple will take care of some other tricky problems, like coherently expressing precisely versioned dependencies across language ecosystem boundaries, correct cross-compilation support, and precise runtime/build-time dependency calculation. ## Doesn't this exist already? No. I've looked. ## Why doesn't this exist already? While I can't answer this for sure, I would posit the following: build systems and package managers are [infrastructure](https://www.destroyallsoftware.com/talks/a-whole-new-world). They cannot be marketed (who would pay for a build system in this day and age?) and need to be rethought from the ground up, so the design and implementation of such is relegated to a select few: academics, bored nerds, and very large companies with insane scaling requirements. Academic research projects are usually left to gather dust once the thesis is said and done. Nerds build toy clones of existing software, except it's going to be better this time. Megacorps don't need their build system to handle reproducibility — they just vendor everything into their humongous monorepo and call it a day. ## Why don't you just ...? Given that existing package managers and build systems overlap in scope with Ripple, this is a perfectly reasonable question to ask. Why not just combine [two](https://github.com/NixOS/nix) [existing](https://bazel.build/) tools which each hold half of the solution? On a surface level, this seems perfectly innocent: reducing the amount of work that has to be put in and avoiding fracturing ecosystems is surely a good thing! Digging deeper, however, you'll quickly realise the following: in order for each side to function efficiently in this arrangement, they need some fairly invasive modifications to integrate with each other. Hard fork territory. So, attempting to reuse existing software would require some fairly significant effort nonetheless, and also involve taking on legacy from the get-go. On the other hand, designing a new system from the ground up will be vastly simpler, as we can entirely do away with the build system/package manager dichotomy and make entire swaths of cross-cutting concerns disappear into thin air. ## Why doesn't *this* exist already? Designing and implementing a project of this scope and complexity is going to require a significant investment of time and energy. It's not something that will get to a usable state in the near future if I'm just tinkering on it at the weekend, so I'm currently seeking funding that would allow me to work on it full-time. Watch this space!