4 ms·

The criticisms the author levies against Protobuf are unfair. Inside Google, all source code is in a monorepo, and depending on other Protobuf files is a matter

The criticisms the author levies against Protobuf are unfair. Inside Google, all source code is in a monorepo, and depending on other Protobuf files is a matter of code-sharing it as a Bazel library; it is trivial. There is no need for a package management system because its existence would be irrelevant.

ronsor 2y ago
> Inside Google, all source code is in a monorepo 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.
- Narhem 2y ago
  Yea, but from the complexities of managing external facing libraries they do an extremely well job. As a former Googler I can jump into bazel, grpc projects or start my own relatively easily. 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.
  - kelnos 2y ago
    As a not-former-Googler, the last time I looked into Bazel I was confused and had no idea what I was looking at. The world is much much much bigger than Google's internal tooling. Even Google's internal tooling that they've made public.
  - marvin-hansen 2y ago
    That is true. I am using Bazel daily with all deps vendored and proto defined as targets so there is really no need for these tools the author mentioned because with Bazel the underlying problems simply don't exist in the first place. 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.
    - troupo 2y ago
      > 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. 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
      - crustycoder 2y ago
        It's a stupid statement internally as well. Unless you can freeze time itself, deploying new versions of stuff isn't instantaneous. And what happens if you need to do a rollback of a component?
        SR2Z 2y ago
        > And what happens if you need to do a rollback of a component? 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.
        troupo 2y ago
        Until you run into things like "your partners deploy once every two months" or "the team's deploy is delayed by X due to unforseen changes downstream" or ... Protobuf is built specifically for Google and Google's way of doing things. Not everyone is built like Google.
        lopkeny12ko 2y ago
        Well, the core problem is that you shouldn't be deploying as infrequently as every 2 months...you should spend engineering energy to fix that rather than on working around it.
kelnos 2y ago
If Google wants to push gRPC as a general, open, standardized solution -- which they most certainly want, and have done -- then they need to cater to how everyone does things, not to how Google does things.
- ai_slurp_bot 2y ago
  In a sense, everyone does things because of how google does things. How does one decide whether the chicken or the egg should follow?
  - codeflo 2y ago
    In what sense does "everyone do things because of how google does things"?
forrestthewoods 2y ago
Nonsense. The criticism are perfectly fair and realistic. 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!
- tourist2d 2y ago
  [dead]
laidoffamazon 2y ago
How is it unfair? Is protobuf an externally available tool or not?

ronsor 2y ago

> Inside Google, all source code is in a monorepo 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.

Narhem 2y ago
Yea, but from the complexities of managing external facing libraries they do an extremely well job. As a former Googler I can jump into bazel, grpc projects or start my own relatively easily. 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.
- kelnos 2y ago
  As a not-former-Googler, the last time I looked into Bazel I was confused and had no idea what I was looking at. The world is much much much bigger than Google's internal tooling. Even Google's internal tooling that they've made public.
- marvin-hansen 2y ago
  That is true. I am using Bazel daily with all deps vendored and proto defined as targets so there is really no need for these tools the author mentioned because with Bazel the underlying problems simply don't exist in the first place. 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.
  - troupo 2y ago
    > 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. 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
    - crustycoder 2y ago
      It's a stupid statement internally as well. Unless you can freeze time itself, deploying new versions of stuff isn't instantaneous. And what happens if you need to do a rollback of a component?
      - SR2Z 2y ago
        > And what happens if you need to do a rollback of a component? 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.
        troupo 2y ago
        Until you run into things like "your partners deploy once every two months" or "the team's deploy is delayed by X due to unforseen changes downstream" or ... Protobuf is built specifically for Google and Google's way of doing things. Not everyone is built like Google.
        lopkeny12ko 2y ago
        Well, the core problem is that you shouldn't be deploying as infrequently as every 2 months...you should spend engineering energy to fix that rather than on working around it.

kelnos 2y ago

If Google wants to push gRPC as a general, open, standardized solution -- which they most certainly want, and have done -- then they need to cater to how everyone does things, not to how Google does things.

ai_slurp_bot 2y ago
In a sense, everyone does things because of how google does things. How does one decide whether the chicken or the egg should follow?
- codeflo 2y ago
  In what sense does "everyone do things because of how google does things"?

forrestthewoods 2y ago

Nonsense. The criticism are perfectly fair and realistic. 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!

tourist2d 2y ago
[dead]

laidoffamazon 2y ago

How is it unfair? Is protobuf an externally available tool or not?