gRPC arguably isn't anything like CORBA. It's just RPC.
The thing that CORBA (and COM/DCOM) gives you on top of RPC is object references, what's called location transparency in DCOM. That is, if you have an API like this:
*Pie getPie()
then the remote server simply returns an object reference. What you have on the client-side is a "stub" (what COM/DCOM calls a proxy), which might look like this:
class Pie {
int getSize()
}
The whole idea is that Pie pretends to be a local object, but it is in fact just a thin wrapper; calling getSize() invokes in a remote network call to the server.
gRPC and other modern RPCs don't have object identity or objects. They just return structs, and you have to invent your own IDs. So in gRPC, the server may expose:
rpc GetPie(PieRequest) returns (PieResponse) {}
But PieResponse is just data. It has no actions.
Where things become insane is where you have big graphs of objects, some of which may be remote references (stubs), some local in your own app. Maybe you accidentally store a reference in a global/static variable, which means your application is effectively holding the remote object "open". Performance typically goes out the window because just calling a method, even if it's data like getSize(), results in a network roundtrip.
I still think the underlying ideas were sane: Defining type-safe, portable interfaces using an IDL, then generate client and server code from that IDL. RPC has been reinvented many times, and gRPC won't be the last iteration. I do suspect we could have something CORBA-ish working over the Internet if we can get the technical design right.