And outside Google, it isn't. It's fair to judge something that's been released to the public based on what the public can reasonably do.
I tried making a few guides on a personal blog explaining how to use these tools but to be honest without seeing how they get used within Google it's relatively difficult to understand why they have some of the design decisions which may seem as clunky initially.
The world is much much much bigger than Google's internal tooling. Even Google's internal tooling that they've made public.
It's worth pointing out that it takes a bit of time and pain to gronk the underlying rational for some of the less obvious design decisions.
For example, Protos aren't versioned because you already version them with git. Releases usually some kind of hash, so you already have reliable dependencies with checksums. No point in versioning protos again. It's a mono repo, so why bother with distribution? Composition? Use proto lib target...
Without Bazel, though, your basically totally lost and then these tools kinda make sense as a way out of the pain caused the lacking tool support you will face.
That said, a lot of orgs have less then ideal IT for historical or whatever reasons so these problems are 100% real and these solutions exist for a reason.
Sorry, but this is such a stupid statement. You external service or client doesn't have access to your internal git hash
> That said, a lot of orgs have less then ideal IT for historical or whatever reasons
No. A lot of orgs don't require setting up Bazel to make simple things like generating code from protobufs work
Including the build commit is very straightforward - but more to the point, Google projects frequently treat the monorepo like a service to do things like fetch the latest config. Even deployments tend to be automated through the monorepo - lots of tools make automated change requests.
You revert the offending commit. That triggers an automatic deploy (or, even more likely, your buggy change gets caught in the canary stage and automatically reverted for you).
The Google philosophy is called "live at head" and it has a bunch of advantages, provided your engineers are disciplined enough to follow through.
Protobuf is built specifically for Google and Google's way of doing things. Not everyone is built like Google.
Yes, Google's internal infrastructure is that good. It's easy to get caught up in the "haha cancel products" meme and forget that this company does some serious engineering.
Bazel is virtually unusable outside of Google. If protobuf is only usable inside Google infra then the response would be “don’t use it if you aren’t Google”. And yet I somehow doubt that’s what you’d argue!