3 ms·

After gogoproto I'm hesitant to depend on another non-standard implementation, getting off gogo was a pain. This thing may be better than the one from Google (g

by usrnm 3mo ago

After gogoproto I'm hesitant to depend on another non-standard implementation, getting off gogo was a pain. This thing may be better than the one from Google (gogo definitely was), but can we be sure that it will still be around in 10 years?

didip 3mo ago
What was the backstory of gogoproto?
- usrnm 3mo ago
  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.
  - Intralexical 3mo ago
    This is concerning to hear. What do Protobufs accomplish, that requires them to be a constantly moving target?
    - arccy 3mo ago
      https://www.youtube.com/watch?v=HTIltI0NuNg 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.
      - usrnm 3mo ago
        If I remember correctly, what finally broke the camel's back was the new API that Google introduced. But I may be wrong
    - esrauch 3mo ago
      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.
crabbone 3mo ago
Hey. I wrote another Python implementation of Protobuf. (protopy https://gitlab.com/doodles-archive/protopy https://gitlab.com/doodles-archive/protopy it was a while ago and haven't touched it since). I'm not saying it's better than whatever this is or that it's any good, I just post it as a proof of sorts that I'm familiar with the problem. So, without further ado: Protobuf isn't a standard. You can't have a non-standard implementation of something that doesn't have a standard to begin with. In reality, you have Google's implementation for C++ and then everything else. Everything else was, for the most part, not written by Google. And it doesn't always align 100% with the C++ Google's stuff. Furthermore, C++ implementation has a lot of idiosyncrasies specific to that language that can't be translated one-to-one into other languages, or, in some cases, shouldn't be, even if they could (eg. C++ implementation is all about source code generation because generating runtime entities s.a. classes in C++ is very difficult, while in languages like Python, generating classes at runtime is easy.) Furthermore, C++ implementation has a specific way of parsing the binary payload (lazy: only the top definitions are parsed, the inner structure of messages is parsed on-demand). But, is this how every parser should behave? What if you want a SAX-like parser? ---- In the hindsight, I just think that Protobuf is not a good format for writing reliable software that aims for decades of usage. We, as in the whole programming world, don't have good formats in general, and whenever we come to the point of having to use some, we either go with an existing popular but crooked or roll our own, probably also crooked. The standard you alluded to would've been great (perhaps a refinement of ASN with more attention to parser implementation, more concrete versions etc.?) But we aren't there yet, and there isn't even a work group to try and address the issue.
- squirrellous 3mo ago
  Honest question - why isn’t the following document [1] a standard? Is it too loosely specified? [1] https://protobuf.dev/programming-guides/encoding/ https://protobuf.dev/programming-guides/encoding/
  - 7bit 3mo ago
    Maybe He means because it diesen have an accepted rfc
newswangerd 3mo ago
Buf is well established and maintains a lot of protobuf packages for many languages, including the YAML implementation for go.
- lyu07282 3mo ago
  Going strong since 2019! It's a wonderful company entirely dedicated to making google's miserable protobuf "somewhat" useable.
igetspam 3mo ago
Can you be sure Google’s ${anything} will be around in 6 months? They have a decades long habit of dumping things that have major use but aren’t novel internally. Worrying about the next 10 years isn’t something you can honestly do when you your argument includes Google owning a thing. Bias: I fought for things like Reader from the inside. If it doesn’t move needles, it goes away.

by usrnm 3mo ago

didip 3mo ago

What was the backstory of gogoproto?

usrnm 3mo ago
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.
- Intralexical 3mo ago
  This is concerning to hear. What do Protobufs accomplish, that requires them to be a constantly moving target?
  - arccy 3mo ago
    https://www.youtube.com/watch?v=HTIltI0NuNg 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.
    - usrnm 3mo ago
      If I remember correctly, what finally broke the camel's back was the new API that Google introduced. But I may be wrong
  - esrauch 3mo ago
    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.

crabbone 3mo ago

Hey. I wrote another Python implementation of Protobuf. (protopy https://gitlab.com/doodles-archive/protopy https://gitlab.com/doodles-archive/protopy it was a while ago and haven't touched it since). I'm not saying it's better than whatever this is or that it's any good, I just post it as a proof of sorts that I'm familiar with the problem. So, without further ado: Protobuf isn't a standard. You can't have a non-standard implementation of something that doesn't have a standard to begin with. In reality, you have Google's implementation for C++ and then everything else. Everything else was, for the most part, not written by Google. And it doesn't always align 100% with the C++ Google's stuff. Furthermore, C++ implementation has a lot of idiosyncrasies specific to that language that can't be translated one-to-one into other languages, or, in some cases, shouldn't be, even if they could (eg. C++ implementation is all about source code generation because generating runtime entities s.a. classes in C++ is very difficult, while in languages like Python, generating classes at runtime is easy.) Furthermore, C++ implementation has a specific way of parsing the binary payload (lazy: only the top definitions are parsed, the inner structure of messages is parsed on-demand). But, is this how every parser should behave? What if you want a SAX-like parser? ---- In the hindsight, I just think that Protobuf is not a good format for writing reliable software that aims for decades of usage. We, as in the whole programming world, don't have good formats in general, and whenever we come to the point of having to use some, we either go with an existing popular but crooked or roll our own, probably also crooked. The standard you alluded to would've been great (perhaps a refinement of ASN with more attention to parser implementation, more concrete versions etc.?) But we aren't there yet, and there isn't even a work group to try and address the issue.

squirrellous 3mo ago
Honest question - why isn’t the following document [1] a standard? Is it too loosely specified? [1] https://protobuf.dev/programming-guides/encoding/ https://protobuf.dev/programming-guides/encoding/
- 7bit 3mo ago
  Maybe He means because it diesen have an accepted rfc

newswangerd 3mo ago

Buf is well established and maintains a lot of protobuf packages for many languages, including the YAML implementation for go.

lyu07282 3mo ago
Going strong since 2019! It's a wonderful company entirely dedicated to making google's miserable protobuf "somewhat" useable.

igetspam 3mo ago

Can you be sure Google’s ${anything} will be around in 6 months? They have a decades long habit of dumping things that have major use but aren’t novel internally. Worrying about the next 10 years isn’t something you can honestly do when you your argument includes Google owning a thing. Bias: I fought for things like Reader from the inside. If it doesn’t move needles, it goes away.