4 ms·

I looked at capn proto as well, but ultimately decided against it because the common view online was grpc was much better at rpc. Maybe it's gotten better since

I looked at capn proto as well, but ultimately decided against it because the common view online was grpc was much better at rpc. Maybe it's gotten better since then, but capnproto at the time was really comparable to protobufs and not grpc.

maccard 9y ago
Last time I looked, capn porto was a no-go on Windows for RPC.
- kentonv 9y ago
  That was fixed in version 0.6: https://capnproto.org/news/2017-05-01-capnproto-0.6-msvc-json-http-more.html https://capnproto.org/news/2017-05-01-capnproto-0.6-msvc-jso...
  - maccard 9y ago
    Wow, great. I last looked in around march. I'll take a look as I'm currently unhappy with thrift.
    - kod 9y ago
      What are you unhappy with in Thrift?
      - maccard 9y ago
        Sorry, I only saw this today. We're using the c++ bindings, and having severe performance problems, particularly the speed of the serialisation. The generated code is not particularly efficient(maps of strings to function pointers) and not very modern. The code itself relies on boost shared pointers everywhere, which is hugely wasteful, and the actual process of getting thrift up and running was on trivial on windows. (Still, easier than grocery was and capn porto at the time). The compiler itself is a bit funny, and hasn't been particularly easy to integrate into our build system (cmake).
kentonv 9y ago
Cap'n Proto includes both serialization (comparable to protobuf) and RPC (comparable to gRPC). The main argument I've heard in favor of gRPC is that it is supported in more languages. Otherwise, I'm not sure what would make gRPC "much better at RPC" -- Cap'n Proto is actually much more expressive, and has features like capabilities and promise pipelining which gRPC lacks. Do you remember the arguments you saw? I'd be curious to know what they were. (Disclosure: I'm the author of Cap'n Proto and also Protobuf v2.)
- _ydfu 9y ago
  In my experience, RPC in gRPC was nicer to work with but Cap'n'Proto's RPC was faster (due to the format I believe). Why was gRPC nicer to work with in my opinion? - Comprehensive and readable documentation. Cap'n'Proto has a high level overview on the main page but the documentation is far from complete. For example regarding I/O, a core part of many RPC systems, "Function calls that do I/O must do so asynchronously, and must return a “promise” for the result." is said, then no explanation is given on how to implement a function that does it (all the examples assume an existing library returns kj promises and since that's custom, no such libraries exist). For serialization, how do I build a list of integers? The "Lists" section on the serialization page doesn't explain this at all, it only mentions the init method for lists of lists or lists of blobs. The gRPC docs on the other hand are quite good, with numerous easy to read tutorials and examples. - Built in support for threading. An event loop is limited to the throughput of a single core and there'll always be a point at which you need either threading or multiple processes. Since I don't want to have a bunch of different copies of a particular thing in memory, it works better for me to have a bunch of threads with access to shared memory. Again, the docs say "While multiple threads are allowed, each thread must have its own event loop." but don't document how to do it (and particularly, do it while sharing a port). Plus, there's no suggestions on how to return a promise that's fulfilled by another thread (this was and still is a big problem for me, I still haven't figured it out). gRPC makes this dead simple by just using threads (or a queue system I haven't looked into much yet). - No kj. I might be more okay with it if the documentation was better but at the moment it's near-nonexistent and wandering around the code base for ~30 mins just to figure out how to construct and return a promise was pretty painful. Really, you can sum up most of my problems in one word: Documentation. Oh and as you said, language support. The Python driver is really important to me yet seems unfinished.

maccard 9y ago

Last time I looked, capn porto was a no-go on Windows for RPC.

kentonv 9y ago
That was fixed in version 0.6: https://capnproto.org/news/2017-05-01-capnproto-0.6-msvc-json-http-more.html https://capnproto.org/news/2017-05-01-capnproto-0.6-msvc-jso...
- maccard 9y ago
  Wow, great. I last looked in around march. I'll take a look as I'm currently unhappy with thrift.
  - kod 9y ago
    What are you unhappy with in Thrift?
    - maccard 9y ago
      Sorry, I only saw this today. We're using the c++ bindings, and having severe performance problems, particularly the speed of the serialisation. The generated code is not particularly efficient(maps of strings to function pointers) and not very modern. The code itself relies on boost shared pointers everywhere, which is hugely wasteful, and the actual process of getting thrift up and running was on trivial on windows. (Still, easier than grocery was and capn porto at the time). The compiler itself is a bit funny, and hasn't been particularly easy to integrate into our build system (cmake).

kentonv 9y ago

Cap'n Proto includes both serialization (comparable to protobuf) and RPC (comparable to gRPC). The main argument I've heard in favor of gRPC is that it is supported in more languages. Otherwise, I'm not sure what would make gRPC "much better at RPC" -- Cap'n Proto is actually much more expressive, and has features like capabilities and promise pipelining which gRPC lacks. Do you remember the arguments you saw? I'd be curious to know what they were. (Disclosure: I'm the author of Cap'n Proto and also Protobuf v2.)

_ydfu 9y ago
In my experience, RPC in gRPC was nicer to work with but Cap'n'Proto's RPC was faster (due to the format I believe). Why was gRPC nicer to work with in my opinion? - Comprehensive and readable documentation. Cap'n'Proto has a high level overview on the main page but the documentation is far from complete. For example regarding I/O, a core part of many RPC systems, "Function calls that do I/O must do so asynchronously, and must return a “promise” for the result." is said, then no explanation is given on how to implement a function that does it (all the examples assume an existing library returns kj promises and since that's custom, no such libraries exist). For serialization, how do I build a list of integers? The "Lists" section on the serialization page doesn't explain this at all, it only mentions the init method for lists of lists or lists of blobs. The gRPC docs on the other hand are quite good, with numerous easy to read tutorials and examples. - Built in support for threading. An event loop is limited to the throughput of a single core and there'll always be a point at which you need either threading or multiple processes. Since I don't want to have a bunch of different copies of a particular thing in memory, it works better for me to have a bunch of threads with access to shared memory. Again, the docs say "While multiple threads are allowed, each thread must have its own event loop." but don't document how to do it (and particularly, do it while sharing a port). Plus, there's no suggestions on how to return a promise that's fulfilled by another thread (this was and still is a big problem for me, I still haven't figured it out). gRPC makes this dead simple by just using threads (or a queue system I haven't looked into much yet). - No kj. I might be more okay with it if the documentation was better but at the moment it's near-nonexistent and wandering around the code base for ~30 mins just to figure out how to construct and return a promise was pretty painful. Really, you can sum up most of my problems in one word: Documentation. Oh and as you said, language support. The Python driver is really important to me yet seems unfinished.