Are build systems typically CPU bound, even during heavy operations such as calculating dependency closure (or other things I'm unaware of)? If not, the I don't see a need to use a language that doesn't provide high level, somewhat costly, but easy to use and understand abstractions. And if it's faster than its competitors and it weighs less, then there's also nothing wrong with calling it "fast" and "lightweight" (though I have no idea whether please fulfills this)
Build system performance tends to be IO-bound, but responsiveness for things like no-op builds tends to be CPU-bound -- and the JVM in particular really suffers. Optimizing IO performance makes it perform better, while optimizing CPU performance makes it feel better to use.
Arguably, making tools feel better to use is more important than raw performance. When you're doing a no-op build, the difference between 100 milliseconds and 500 is large, and the difference between 10ms and 100 is enormous.
> Optimizing IO performance makes it perform better, while optimizing CPU performance makes it feel better to use.
Optimizing I/O performance certainly makes building software feel better though. Running make on a tmpfs directory feels absolutely amazing. It feels even better on subsequent runs since Linux uses free memory to cache files.
My full time job was to make Bazel more efficient for about 1.5 years. The answer is: it really depends.
If you are executing 100,000 novel parallel C++ actions, then compilation for that might be I/O bound? If these actions are all cached though you would likely be CPU bound instead, as the build system works hard to discover that all the work is already done.
