From f5c8a8537a336b60fd28af003572fa8883fc8354 Mon Sep 17 00:00:00 2001 From: V Date: Thu, 25 Feb 2021 21:17:45 +0100 Subject: ripple/website: init This contains the source to Ripple's website, as it was published on 2020-10-07. Change-Id: I4c871be79d8841b277d23ea741c8728ec5da8cc8 --- ripple/website/pages/index.md | 74 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 ripple/website/pages/index.md (limited to 'ripple/website/pages') diff --git a/ripple/website/pages/index.md b/ripple/website/pages/index.md new file mode 100644 index 0000000..3fac3ac --- /dev/null +++ b/ripple/website/pages/index.md @@ -0,0 +1,74 @@ +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! -- cgit 1.4.1