What does fast CI even mean?
CI is an overgrown shell script running your build and telling you when it fails. In general build tooling has gotten so slow that the cost of whatever CI runner relative to it should be nil.
If you want fast CI you need fast tsc, clang, rustc, etc... not a faster program that calls exec on them.
A bit more on topic, if you're selling CI and your business fails it's because people you're providing no value - people can run their build scripts fine without you.
Perusing this article quickly, it means a CI that is automatically handling things like caching build artifacts so that you don't need to recompile your entire repository every single commit. It's not about a faster program to call exec; it's about a program that knows it need not even call exec.
Incremental builds are something even enterprise build systems fail at.
I've had Visual Studio and MSBuild fail on me multiple times by deciding not to recompile a certain .cpp file, because they got the dependency graph wrong. This results in a running but inconsistent executable that's a bitch to debug.
If you're selling me another tool that duplicates this work, but that has even less context on my project than the build system, I'll pass.
Bazel does this.
I have to be honest - MS Build does not scale well. Companies use it because it’s the default.
Doesn't seem fully baked yet though