[kyle787]

Originally, I was going to complain that this is more of a critique of the grpc ecosystem rather than protocol.

IMO, readability of generated code, is largely a non concern for the vast majority use cases. Additionally, if anything it's more so a criticism of the codegen tool. Same with the complaints around the http server used with go.

However, I totally agree with criticisms of the enum naming conventions. It's an abomination and super leaky. Made worse by the fact it's part of the official(?) style guide https://protobuf.dev/programming-guides/style/#enums

[enneff]

To be fair, the ecosystem is kind of inextricably tied to the protocol. I’m not aware of any other production grade Go gRPC implementations besides the official one.

[kyle787]

But grpc isn't limited to go. Criticizing gprc, as a whole, for the http library used with go isn't valid. However, it's fair to take issue with the choice of http library used by the most popular go codegen tool.

[alecthomas]

Connect [1] is one and it's fantastic. The Go implementation in particular is much nicer than grpc-go.

[1] https://connectrpc.com/

[enneff]

Wow that’s awesome! I wasn’t aware of this.

[kelnos]

> IMO, readability of generated code, is largely a non concern for the vast majority use cases

Completely disagree. More often than I'd like to, I've had to read generated code from various codegen tools in order to figure out what it was doing (in order to fix my usage of that code where I was making bad assumptions about the generated interface) or figure out why the generated code wasn't doing what it was supposed to (because it was was buggy). All code eventually needs to be read by someone, even code that's generated on the fly during the build process.

[marvin-hansen]

I read the generated code quite often and each time it boggles my mind who in the world came up with that crap. The readability and code quality is seriously awful and it is a valid criticism. When the generated code indeed is buggy, this a double whammer.

However, it is also true that a lot of devs don't read it or simply don't care so I would argue it is mostly a non-issue in practice contrary to what the author of the article suggest. My life is certainly not affected by ugly generated code.

Also, worth mentioning, when I wrote code generators in the past, albeit less complex, it's rarely the common case that makes the generated code ugly, but rather the coverage of a gazillion corner cases.

Can the generatee code be 2-4% faster? Sure. Is anyone updating the code generator for that? Well, if you feel the small gain is worth the pain of touching a fairly complicated generator that produces already monstrous code, patch it, test it, and fill a PR. Point is, none of the proto maintainer is moving a finger for 2% better.

[kyle787]

In that case, I would imagine you would struggle with any clients generated via an IDL. The same "issue" occurs with openapi/swagger generated clients.

If you're not working on whatever is responsible for generating the code, you're not supposed to have to look under the hood. The whole purpose is to abstract away the implementation details, it's contract driven development. If you find yourself frequently needing to read the underlying code to figure out what's going on, the problem isn't with the tool, it's elsewhere.

[Groxx]

>In that case, I would imagine you would struggle with any clients generated via an IDL. The same "issue" occurs with openapi/swagger generated clients.

Sometimes. Only sometimes. And that doesn't mean it's not a problem there either.

Abstractions that completely abstract what they wrap can claim "no need to look under the hood", but generated RPC code fails miserably there when something fails or changes, particularly during code generation (where you can't usually even get partial data / intermediate state, just "it crashed in this core loop that is executed tens of thousands of times, good luck").

And on this front, protobuf and gRPC are rather bad. Breaking changes are somewhat frequent, almost never have a breaking semver change so they surprise everyone, and for some languages (e.g. Go) they cannot coexist with the previous versions.

Figuring out what broke, why, and how to work around or fix or just live with it is made vastly more difficult by unreadable generated code.