Google has a lot of tools are are best-in-class— if you spend a large fixed cost setting them up and get everyone to use them. Obviously this is easy for Google to justify: they spent the fixed cost once ten years ago, and now that everyone uses the product, it's easy for new products to integrate too. But it makes them hard to spread outside Google itself.

Bazel, Google's build tool is a good example of this. Google actually open-sourced most of Bazel a few years ago, but as far as I know, it hasn't gotten much uptake. It requires doing a bunch of boring configuration work to use it. But as someone who used it internally I definitely prefer it to all the alternatives, due to its speed and reliability.

(I work on Bazel)

Although Bazel is still in beta, more and more companies are using it (e.g. Dropbox, Huawei, SpaceX, Pinterest, Stripe - see https://github.com/bazelbuild/bazel/wiki/Bazel-Users) or interested enough to attend the recent Bazel conference (see https://conf.bazel.build/about).

I wish you allowed people to be more open about how you build and deploy software at Google. I asked about how a change in an angular website gets to production and the response was that they didn't know completely and wouldn't know how much they're allowed to share even of the things they do know.

I can imagine there is some fear of espionage or sabotage but I'm just asking the boring stuff about deploying a (web) front end system.

Their distributed build system is better, and they have better tools for debugging distributed system problems.

My impression is that for local stuff their tooling is not much better than public. They have a lot more reliance on logging.

I’ve never worked there so this is just all second hand info.

I find it interesting that feedback like this still abounds (and for good reason), considering the many tools and frameworks and services available online today. Apparently the field for delivering another tool or service continues to remain green :)