[rektide]

I don't think of gRPC as object oriented, but I don't have a ton of experience with it. It seems like a service oriented system, with endpoints that accept parameters & return data. There's not, to my knowledge, much in the way of enduring objects.

You're not going to have dozens of Todo objects that you are callinng methods on. You're going to have a TodoService that has some methods. This is isn't very object oriented; the things sent in & out are just dumb data, it's just request/response.

I think cap'n'proto gets a little closer to having an actual notion of objects, in that the protocol has actual identifiers built in. But it's still more about services than objects.

Corba seemed to really be object oriented; you'd get back todo1 and call todo1.done().

[kentonv]

> I think cap'n'proto gets a little closer to having an actual notion of objects, in that the protocol has actual identifiers built in. But it's still more about services than objects.

Cap'n Proto is all about the objects! I would say this is the whole point of the design, and my main motivation in creating it.

(Unlike CORBA, though, Cap'n Proto does not try to pretend that RPCs are equivalent to local calls. In particular it has promise pipelining to compensate for latency, rather than pretending there is no latency. https://capnproto.org/rpc.html)