Bazel is on its way to be more like Google’s internal implementation: distributed builds, object file cache, distributed tests. That means your C++ build and test runs will take barely any time at all, same as they do at Google. That, in turn, enables the kind of velocity unachievable through other means.

I seem to find many sources that Googlers spend heaps of time waiting for test runs. Apparently they're required for about everything you do with code at Google and are the but of dozens of jokes.

All of which makes me think that maybe Google's internal building of code isn't that fast. Or perhaps it's fast, but only in relative terms (as in you're still waiting a few minutes for hello world, but huge programs build "fast", as in a few dozen minutes)

I did test it on hello world, and euhm ... It's not fast. The first build of it is horribly slow (double digit minutes, wtf is it doing ?). Second build is "fast" which should be understood to still be double digit seconds. Running the same program in VSCode and just compiling it with the system-installed compiler is so fast you see the output before the VSCode has finished drawing the terminal window.

Reading the site I also get the impression that Bazel's singular focus is correctness. They don't mind things being ridiculously slow if it increases the odds of being a correct build.

I'm sorry but, "bwahahahha". C++ build and test times at Google are astronomical. It's one of the reasons go exists: they built it to compile and link faster.

If a minute to build and link half a million lines of C++ is “astronomical”, then sure. Try to build that on your local box, then get back to me. Go exists solely because Rob Pike had nothing better to do, and a lot of googlers hate Java.

Yeah, I actually build locally. It takes a while up front (about half an hour) to build Hello World but incrementals are fast.

Bazel does use namespaces on Linux. It's how it can prevent you from accessing files you didn't declare as dependencies.