Like the sibling said, there's a complimentary _builder struct generated with a Build() method. For instance, for the sample message in the blog post, here's the public API of the generated _builder:

  type LogEntry_builder struct {
   BackendServer *string
   RequestSize   *uint32
   IpAddress     *string
   // contains filtered or unexported fields
  }

  func (b0 LogEntry_builder) Build() *LogEntry

So they managed to screw up even that. The naming system is not idiomatic Go.

You still will need to create temporary objects (performance...) and for an unclear gain.

> The naming system is not idiomatic Go.

Underscores are commonly used in names in generated code to avoid conflicts (this applies to all sorts of codegen, not just protobuf). You can easily have both Foo and FooBuilder messages in your protobuf. See also generated enum consts since day one of protobuf-gen-go.

> used in names in generated code

Fair enough but now this name leaks out into code I have to type. I don't dig highly opinionated languages with tooling that complains at me over style guidelines breaking their own style guidelines to solve a problem that they themselves have created.

They painted themselves into a corner and their solution is for me to hit myself in the head with a hammer.

If a generated name clashes, then you just override the generated name.

And in this case, perhaps, the resistance and the ugliness of the solution should have made the Protobuf authors to pause for a bit and rethink it.

Several years ago, I used gogoprotobuf instead of regular Go protobuf. It uses normal by-value structures instead of pointers everywhere, with generated code for s11n instead of reflection. It worked about 10x faster that the regular protobuf.

It's not in the post but when this was rolled out internally at Google there was a corresponding builder struct to initialize from.