4 ms·

I love the cyclical nature of everything in remote execution world. Corba, Remoting, some XML sauce, WCF, Http methods and Url's, some Json sauce, and than gRPC

by gokhan 5y ago

I love the cyclical nature of everything in remote execution world. Corba, Remoting, some XML sauce, WCF, Http methods and Url's, some Json sauce, and than gRPC. Same ideas. Just like having flared trousers every 10 years or so. Payload is binary, it's fast -> Anybody can read the payload but it's structured -> Structure is redundant, look how lightweight is this -> Payload is binary, it's fast The problem in software world is, there's no silver bullet for any particular problem but there are technology fashions claiming otherwise.

dboreham 5y ago
Flared trouser periodicity is 20 years.
xtracto 5y ago
Haha, that was my thought when I started reading about gRPC. Waaay back in the day I remember programming "distributed" systems using Java RMI. For some whatever reason we are coming back full circle to that approach.
cbsmith 5y ago
I couldn't help but read this article through the eyes of CORBA, and the bit about "the olden days" made me crack up even harder.
- marsdepinski 5y ago
  SOAP. I'm waiting for gRPC and OpenAPI to get me where WSDLs were 20 years ago.
  - cbsmith 5y ago
    SOAP was the successor to CORBA really, and then everyone decided it was too complicated and heavy weight. ;-)
atombender 5y ago
On the other hand, past technologies like CORBA, DCOM, and RMI were all object-oriented, whereas gRPC is data-oriented. CORBA (as was DCOM) provided an object model where the client would make method calls to object by identity. This provided "locality transparency" — an object looks identical in the client as in the server. The client object is just a "stub" in CORBA parlance (or "proxy" in DCOM, if I remember correctly), and method calls are transparently translated to RPC calls. The consequence of this is that a client can hold onto entire object graphs, and gets very tightly coupled with the server. For example, a single client can keep tons of objects "open" inside the server just by virtue of having references to them. Very careful tracking of object references would be needed. Both CORBA ans DCOM use explicit reference counting; if a client gets this wrong, it can cause memory leaks inside the server. Not great for scalability, and a big weakness in terms of security. gRPC is more like DCE RPC or Sun RPC, while leveraging a bunch of the web stack which didn't exist back then. There's no denying that technology is cyclical in some ways, of course. But we're not exactly coming full circle. We bring back some things and integrate it into the new stuff. The tooling around gRPC is miles ahead of what we had back then, while being based more or less on the same principles. Interestingly, there's a similar (but maybe more depressing) cyclical story with dynamic vs. static typing in programming language. Python, Ruby, PHP, etc. allowed more people to shift away from commercial tech stacks (especially the horrific Java app server stuff in the early 2000s) while building out super-productive web frameworks. JavaScript allowed us to write web apps that were capable of competing with desktop apps. But in the process we gave up static typing. Millions of person hours have been spent in blogs and discussion boards defending, and extolling the superiority of, dynamic typing — yet this was found (in my view) to be a fallacy, and something of a shared delusion among developers drunk on web frameworks like Rails.
- hiram112 5y ago
  > But in the process we gave up static typing. Millions of person hours have been spent in blogs and discussion boards defending, and extolling the superiority of, dynamic typing — yet this was found (in my view) to be a fallacy, and something of a shared delusion among developers drunk on web frameworks like Rails. Bingo. I learned C++ and then Java first, so I've always been biased towards static typing. When the whole MEAN stack (including non-relational databases i.e. just shoving tons of JSON back and forth) become the cool thing, I refused to buy into the hype and continued using Java, even if it didn't make me popular with the newer developers. And now I make good money cleaning up Node / Python monstrosities that grew too big for dynamic typing to handle. The worst thing about these is that somewhere in the last 4-5 years, the dynamic advocates began to realize that static types really did make sense, and so now they've added all sorts of hacks like Typescript or Python typing libs (Pydantic) and annotations that try to bridge the gap. But it doesn't work. The few actual benefits of "simple" languages like Python and Javascript (e.g. One Way to Do Things and quick prototyping) are a thing of the past. Instead, a typical Python or Express web app now has just as many unintelligible annotations and verbose "interfaces" or model objects as an "enterprise" Java / C# app had 10 years ago. And the pseudo-types aren't even all that helpful. The IDEs can sometimes understand things, but usually not 100% like they would with a Java app. Rarely does auto-complete or large refactoring work. Typing errors aren't always found at "compile" time - still plenty of surprises discovered only at runtime. Readability is just as bad as the typical Java-Spring app with all sorts of magic going on underneath the covers at runtime. There is no way to just glance at a simple controller and understand what's going on without knowledge of increasingly bloated frameworks. It's just a mess. At least I'll have plenty of work for the next decade.

by gokhan 5y ago

dboreham 5y ago

Flared trouser periodicity is 20 years.

xtracto 5y ago

Haha, that was my thought when I started reading about gRPC. Waaay back in the day I remember programming "distributed" systems using Java RMI. For some whatever reason we are coming back full circle to that approach.

cbsmith 5y ago

I couldn't help but read this article through the eyes of CORBA, and the bit about "the olden days" made me crack up even harder.

marsdepinski 5y ago
SOAP. I'm waiting for gRPC and OpenAPI to get me where WSDLs were 20 years ago.
- cbsmith 5y ago
  SOAP was the successor to CORBA really, and then everyone decided it was too complicated and heavy weight. ;-)

atombender 5y ago

On the other hand, past technologies like CORBA, DCOM, and RMI were all object-oriented, whereas gRPC is data-oriented. CORBA (as was DCOM) provided an object model where the client would make method calls to object by identity. This provided "locality transparency" — an object looks identical in the client as in the server. The client object is just a "stub" in CORBA parlance (or "proxy" in DCOM, if I remember correctly), and method calls are transparently translated to RPC calls. The consequence of this is that a client can hold onto entire object graphs, and gets very tightly coupled with the server. For example, a single client can keep tons of objects "open" inside the server just by virtue of having references to them. Very careful tracking of object references would be needed. Both CORBA ans DCOM use explicit reference counting; if a client gets this wrong, it can cause memory leaks inside the server. Not great for scalability, and a big weakness in terms of security. gRPC is more like DCE RPC or Sun RPC, while leveraging a bunch of the web stack which didn't exist back then. There's no denying that technology is cyclical in some ways, of course. But we're not exactly coming full circle. We bring back some things and integrate it into the new stuff. The tooling around gRPC is miles ahead of what we had back then, while being based more or less on the same principles. Interestingly, there's a similar (but maybe more depressing) cyclical story with dynamic vs. static typing in programming language. Python, Ruby, PHP, etc. allowed more people to shift away from commercial tech stacks (especially the horrific Java app server stuff in the early 2000s) while building out super-productive web frameworks. JavaScript allowed us to write web apps that were capable of competing with desktop apps. But in the process we gave up static typing. Millions of person hours have been spent in blogs and discussion boards defending, and extolling the superiority of, dynamic typing — yet this was found (in my view) to be a fallacy, and something of a shared delusion among developers drunk on web frameworks like Rails.

hiram112 5y ago
> But in the process we gave up static typing. Millions of person hours have been spent in blogs and discussion boards defending, and extolling the superiority of, dynamic typing — yet this was found (in my view) to be a fallacy, and something of a shared delusion among developers drunk on web frameworks like Rails. Bingo. I learned C++ and then Java first, so I've always been biased towards static typing. When the whole MEAN stack (including non-relational databases i.e. just shoving tons of JSON back and forth) become the cool thing, I refused to buy into the hype and continued using Java, even if it didn't make me popular with the newer developers. And now I make good money cleaning up Node / Python monstrosities that grew too big for dynamic typing to handle. The worst thing about these is that somewhere in the last 4-5 years, the dynamic advocates began to realize that static types really did make sense, and so now they've added all sorts of hacks like Typescript or Python typing libs (Pydantic) and annotations that try to bridge the gap. But it doesn't work. The few actual benefits of "simple" languages like Python and Javascript (e.g. One Way to Do Things and quick prototyping) are a thing of the past. Instead, a typical Python or Express web app now has just as many unintelligible annotations and verbose "interfaces" or model objects as an "enterprise" Java / C# app had 10 years ago. And the pseudo-types aren't even all that helpful. The IDEs can sometimes understand things, but usually not 100% like they would with a Java app. Rarely does auto-complete or large refactoring work. Typing errors aren't always found at "compile" time - still plenty of surprises discovered only at runtime. Readability is just as bad as the typical Java-Spring app with all sorts of magic going on underneath the covers at runtime. There is no way to just glance at a simple controller and understand what's going on without knowledge of increasingly bloated frameworks. It's just a mess. At least I'll have plenty of work for the next decade.