News for hackers. Stuff that matters.
Re:Protobuf-py: Protobuf for Python, without compromises by usrnm on Sunday July 12, 2026 @05:26AM (#48879664)
The golang implementation of protobuf sucked historically (still does, but is improving) and gogo was an alternative that fixed a lot of problems and was nicer overall. Until its creator burned out and deprecated it. Chasing a constantly moving target that you have no control over is very taxing in the long run.
Re:Protobuf-py: Protobuf for Python, without compromises by Intralexical on Sunday July 12, 2026 @08:51AM (#48880785)
This is concerning to hear. What do Protobufs accomplish, that requires them to be a constantly moving target?
Re:Protobuf-py: Protobuf for Python, without compromises by arccy on Sunday July 12, 2026 @09:43AM (#48881189)
https://www.youtube.com/watch?v=HTIltI0NuNg

I think it's less that protobuf is a moving target, and more that gogo tried to add in all the features that google didn't want to maintain, and learned that maintaining a massive feature matrix was impossible.

Re:Protobuf-py: Protobuf for Python, without compromises by usrnm on Sunday July 12, 2026 @10:01AM (#48881297)
If I remember correctly, what finally broke the camel's back was the new API that Google introduced. But I may be wrong
Re:Protobuf-py: Protobuf for Python, without compromises by esrauch on Sunday July 12, 2026 @06:00PM (#48885254)
GoGo was not a completely separate implementation but deeply hooked into the official GoProto implementation. So it wasn't "Protobuf the binary wire format" or "Protobuf the schema language" which changed over time here, changes to the Google's Go library caused it problems. It's like building a library that integrates with Jackson (a JSON library) and Jackson details changed in ways that added toil, versus JSON changing.