5 ms·

I'm pretty stoked about future cap'n proto developments. In the scenarios where I've brought up Cap'n Proto, all but the most senior/prolific developers have a

I'm pretty stoked about future cap'n proto developments. In the scenarios where I've brought up Cap'n Proto, all but the most senior/prolific developers have a near impossible time of ascertaining why one might want to use capnp over competing approaches (e.g. Protobuf). I think, despite a pretty decent description on the website and my own skills in explaining/teaching, such protocols are nearly impossible for the majority of developers to intuit -- so they're all perceived as being nearly identical, save for financial backing and other forms of social proof. With some of the rough corners filed smooth (e.g. Windows support), a bit more marketing and promotion, and eventually more big names advertising their use of capnp, my job getting buy in from my peers would be much easier.

StreamBright 10y ago
Performance might be one reason to use Cap'n Proto over Protobuf. http://dbeck.github.io/5-lessons-learnt-from-choosing-zeromq-and-protobuf/ http://dbeck.github.io/5-lessons-learnt-from-choosing-zeromq...
deleted 10y ago
[deleted]
hueving 10y ago
Can you provide a 'top 3' list of reasons to use Cap'n Proto over Protobufs?
- doh 10y ago
  1) Cap'n Proto doesn't encode/decode messages thus it's nuch cheaper for processing and memory management 2) protobuf in the proto3 design doesn't cary default values. So if you have a bool field and want to explicitly send false, well you have to change it to some other type or use the default values all the time 3) protobuf generates incredibly large serialization/deserialization support coce for each template. For some languages like Python in can be in hundreds of kilobytes. Cap'n proto messages are significantly smaller There is more for CnP but Protobuf has much better support and is by default used in projects like gRPC. Also new CnP is lacking speed in new development in comparison to Protobuf. But I'm using in one of my side projects and I'm very happy with it
  - hueving 10y ago
    Thanks. Those are pretty significant advantages. These things should be on the home page of the project. That's how smaller projects gain share.
    - andrewstuart2 10y ago
      The first one is, but as the obviously hyperbolic "infinitely faster" claim.
  - skybrian 10y ago
    re: "Doesn't encode/decode messages" Does this mean that individual fields are encoded/decoded lazily?
    - kentonv 10y ago
      Well, you could look at it that way. But the "encoding" is the same encoding that an "int" field in a struct uses, and "decoding" it is a trivial load instruction.
      - lastofus 10y ago
        At what point is byte ordering handled?
        kentonv 10y ago
        The format is little-endian, so it's necessary to use a little-endian load instruction, which almost all architectures (including most big-endian architectures) have. (But every widely-used arch these days is LE.)
  - euyyn 10y ago
    (2) is explicitly one of the reasons to use proto3 over proto2, though :) It's weird seeing it listed as a disadvantage instead of the other way around.

StreamBright 10y ago

Performance might be one reason to use Cap'n Proto over Protobuf. http://dbeck.github.io/5-lessons-learnt-from-choosing-zeromq-and-protobuf/ http://dbeck.github.io/5-lessons-learnt-from-choosing-zeromq...

deleted 10y ago

[deleted]

hueving 10y ago

Can you provide a 'top 3' list of reasons to use Cap'n Proto over Protobufs?

doh 10y ago
1) Cap'n Proto doesn't encode/decode messages thus it's nuch cheaper for processing and memory management 2) protobuf in the proto3 design doesn't cary default values. So if you have a bool field and want to explicitly send false, well you have to change it to some other type or use the default values all the time 3) protobuf generates incredibly large serialization/deserialization support coce for each template. For some languages like Python in can be in hundreds of kilobytes. Cap'n proto messages are significantly smaller There is more for CnP but Protobuf has much better support and is by default used in projects like gRPC. Also new CnP is lacking speed in new development in comparison to Protobuf. But I'm using in one of my side projects and I'm very happy with it
- hueving 10y ago
  Thanks. Those are pretty significant advantages. These things should be on the home page of the project. That's how smaller projects gain share.
  - andrewstuart2 10y ago
    The first one is, but as the obviously hyperbolic "infinitely faster" claim.
- skybrian 10y ago
  re: "Doesn't encode/decode messages" Does this mean that individual fields are encoded/decoded lazily?
  - kentonv 10y ago
    Well, you could look at it that way. But the "encoding" is the same encoding that an "int" field in a struct uses, and "decoding" it is a trivial load instruction.
    - lastofus 10y ago
      At what point is byte ordering handled?
      - kentonv 10y ago
        The format is little-endian, so it's necessary to use a little-endian load instruction, which almost all architectures (including most big-endian architectures) have. (But every widely-used arch these days is LE.)
- euyyn 10y ago
  (2) is explicitly one of the reasons to use proto3 over proto2, though :) It's weird seeing it listed as a disadvantage instead of the other way around.