1. 35

  2. 9

    This rings so true, I’ve been working with these horrible things for the past year, seems like google doesn’t know what a coproduct is (since golang is also missing it, famously).

    The one I want to win this space is https://typedefs.com/, for the simple reason that it is extremely simple both syntax and semantics wise. Just algebraic datatypes in s-expressions.

    Just saw this one in the comments on the article, it looks more mature and similar semantics: https://github.com/timbod7/adl/blob/master/docs/introduction.md

    1. 2

      Just algebraic datatypes in s-expressions.

      S-expressions are a huge improvement over most data exchange formats, they’re ridiculously easy to parse, very compact, and have a lot of potential for extensions. It’s a shame most people don’t know much about them.

      1. 1

        Thx for that link to adl. I rarely read the comments, so I would’ve missed out on that library. It looks nice and clean.

      2. 5

        I remember trying to compile a mumble server for a minimal system once (MIPS router?), but things became very complicated for dependencies such as protobuffers. When I later found out protobuf was a Google project the build complexity started to make sense :)

        1. 7

          This doesn’t discuss the huge advantage protobufs have at google that may even be worth all the pain described: the amount of amazing tooling made is absolute insanity. There are storage formats, sql-like query engines, pretty printers abound, magical serializes that can read/write anything written in the future or past, … the list is much longer and more proprietary.

          The technical and social pressure to make sure your code works with this 10000 engineering years of tooling labor is much much bigger.

          Also they have an interesting claim:

          At the root of the problem is that Google conflates the meaning of data with its physical representation.

          I question anyone that doesn’t think at some point the rubber meets the road. Your encoded data has to have some meaning associated with it at some level.

          When you’re at Google scale, this sort of thing probably makes sense. After all, they have an internal tool that allows you to compare the finances behind programmer hours vs network utilization vs the cost to store x bytes vs all sorts of other things. Unlike most companies in the tech space, paying engineers is one of Google’s smallest expenses. Financially it makes sense for them to waste programmers’ time in order to shave off a few bytes.

          Paying engineers is actually not one of the smallest expenses (look at Google’s quarterly statements, stock-based comp alone is equivalent to ~50% of all capital costs..) and not the purpose of the tool. For all but INSANE amounts of engineering, it’s usually better to waste the network, cpu, disk, whathaveyou than software engineers.

          Finally, I hate protobufs as well and despise I use them in may day-to-day work, but this rant felt really lacking inside and out.

          1. 6

            I think the point is that protobuf may be the right choice for Google, but almost certainly the wrong choice everywhere else.

            1. 1

              magical serializes that can read/write anything written in the future or past,

              Show me a protobuf 3 decompiler that doesn’t depend on .NET

            2. 3

              Looking through the comments, the alternatives all fall short (or make them less optimal) in one way or another for pretty much all of my use cases. I wouldn’t call Protocolbuffers perfect, but I think statements like them being “wrong” or it only being for Goolge are wrong.

              Yes, a lot of what Google produces, does, might not be the right technology, pattern, way of doing things and might even be inferior in every aspect compared to other technology. I also agree that there is a lot of cargo-culting and Google doing it this and that way is a non-argument.

              So I wonder what a better (existing) alternative would be and why.

              1. 2

                We use protobufs at work—it’s been a frictionless system for us. 🤷🏻

                1. 1

                  Protobuf has worked fine with grpc servers. Fulfills any need I have. Used Thrift in the past. Also fine. Both generally ergonomic.

                  Stories with similar links:

                  1. Protobuffers Are Wrong via calvin 10 months ago | 56 points | 51 comments