4 ms·

"5 times faster" reminds me of Cap'n Proto's claim: in benchmarks, Cap’n Proto is INFINITY TIMES faster than Protocol Buffers: https://capnproto.org/ https://ca

by rozenmd 9mo ago

"5 times faster" reminds me of Cap'n Proto's claim: in benchmarks, Cap’n Proto is INFINITY TIMES faster than Protocol Buffers: https://capnproto.org/ https://capnproto.org/

7777332215 9mo ago
In my experience capn proto is much less ergonomic.
- IshKebab 9mo ago
  I agree. It might be faster if you don't actually deserialise the data into native structs but then your codebase will be filled with fairly horrific CapnProto C++ code.
gf000 9mo ago
I mean, cap'n'proto is written by the same person who created protobuf, so they are legit (and that somewhat jokish claim is simply that it requires no parsing).
- Sesse__ 9mo ago
  > I mean, cap'n'proto is written by the same person who created protobuf Notably, Protobuf 2, a rewrite of Protobuf 1. Protobuf 1 was created by Sanjay Ghemawat, I believe.
  - 7e 9mo ago
    Google loves to reinvent shit because they didn't understand it. And to get promo. In this case, ASN.1. And protobufs are so inefficient that they drive up latency and datacenter costs, so they were a step backwards. Good job, Sanjay.
    - notyourwork 9mo ago
      Really dismissive and ignorant take from a bystander. Back it up with your delivery that does better instead of shouting with a pitchfork for no reason.
      - 7e 9mo ago
        This bystander has been using protobufs for more than ten years. I'm not sure what I need to deliver since ASN.1, Cap'n Proto and Flatbuffers are all more efficient and exist already. ASN.1 was on the scene in 1984 and was already more efficient than protobufs.
        kentonv 9mo ago
        Protobuf has far better ergonomics than ASN.1. ASN.1 is an overcomplicated design-by-committee mess. Backwards compatibility in particular is much harder.
        7e 9mo ago
        I don't doubt your experience, but with X.509 having evolved substantially, and ASN.1 on billions (if not tens of billions) of devices, in practice it seems OK. And it was formally verified early.
        sph 9mo ago
        ASN.1 on billions of devices doesn’t make it less of an anti-ergonomic, design-by-committee piece of crap. Unless your goal is to be binary-compatible with these devices, one should be free to explore alternatives. By all means, keep using it, but it might be worth figuring out why other people don’t. Hint: it’s not because they’re more stupid than you or are looking to get promoted by big G. (Personally, I like the ideas and binary encoding behind Capn Proto more than all the alternatives)
        gorset 9mo ago
        One of the advantages of of protobuf I never see anyone highlight is how neat and well-designed the wireformat is, in terms of backward/forward compatibility and lowlevel stuff you can do with it. Very useful when building big and demanding systems over time. For high performance and critical stuff, SBE is much more suitable, but it doesn't have as good of a schema evolution story as protobuf.

by rozenmd 9mo ago

"5 times faster" reminds me of Cap'n Proto's claim: in benchmarks, Cap’n Proto is INFINITY TIMES faster than Protocol Buffers: https://capnproto.org/ https://capnproto.org/

7777332215 9mo ago

In my experience capn proto is much less ergonomic.

IshKebab 9mo ago
I agree. It might be faster if you don't actually deserialise the data into native structs but then your codebase will be filled with fairly horrific CapnProto C++ code.

gf000 9mo ago

I mean, cap'n'proto is written by the same person who created protobuf, so they are legit (and that somewhat jokish claim is simply that it requires no parsing).

Sesse__ 9mo ago
> I mean, cap'n'proto is written by the same person who created protobuf Notably, Protobuf 2, a rewrite of Protobuf 1. Protobuf 1 was created by Sanjay Ghemawat, I believe.
- 7e 9mo ago
  Google loves to reinvent shit because they didn't understand it. And to get promo. In this case, ASN.1. And protobufs are so inefficient that they drive up latency and datacenter costs, so they were a step backwards. Good job, Sanjay.
  - notyourwork 9mo ago
    Really dismissive and ignorant take from a bystander. Back it up with your delivery that does better instead of shouting with a pitchfork for no reason.
    - 7e 9mo ago
      This bystander has been using protobufs for more than ten years. I'm not sure what I need to deliver since ASN.1, Cap'n Proto and Flatbuffers are all more efficient and exist already. ASN.1 was on the scene in 1984 and was already more efficient than protobufs.
      - kentonv 9mo ago
        Protobuf has far better ergonomics than ASN.1. ASN.1 is an overcomplicated design-by-committee mess. Backwards compatibility in particular is much harder.
        7e 9mo ago
        I don't doubt your experience, but with X.509 having evolved substantially, and ASN.1 on billions (if not tens of billions) of devices, in practice it seems OK. And it was formally verified early.
        sph 9mo ago
        ASN.1 on billions of devices doesn’t make it less of an anti-ergonomic, design-by-committee piece of crap. Unless your goal is to be binary-compatible with these devices, one should be free to explore alternatives. By all means, keep using it, but it might be worth figuring out why other people don’t. Hint: it’s not because they’re more stupid than you or are looking to get promoted by big G. (Personally, I like the ideas and binary encoding behind Capn Proto more than all the alternatives)
        gorset 9mo ago
        One of the advantages of of protobuf I never see anyone highlight is how neat and well-designed the wireformat is, in terms of backward/forward compatibility and lowlevel stuff you can do with it. Very useful when building big and demanding systems over time. For high performance and critical stuff, SBE is much more suitable, but it doesn't have as good of a schema evolution story as protobuf.