6 ms·

I mean, they even had their own CORBA broker!

stickfigure 5y ago
Unpopular opinion: CORBA was underrated. For its time, CORBA was a decent way of stitching together heterogeneous systems. Tediously hand-coding REST APIs was a big step backwards, and gRPC is really just catching up to where we were before.
- poulsbohemian 5y ago
  Thank you!! I did my undergrad thesis around CORBA (showing my age…) and you are spot on that the whole world proceeded to pile on a whole lot of work in order to make everything run over http.
- scrumper 5y ago
  I remember learning about CORBA in undergrad too. Then a few months into my first job, "new guy, go do this integration with SOAP/WSDL." Crushed me so hard I went into sales.
  - AnotherGoodName 5y ago
    The 'never again' part of working with soap for me was that Microsofts and Javas soap libraries were more or less incompatible for a variety of reasons. I could handle the xml madness but at least make sure the standard is a standard. I'm pretty happy with rest apis on that front. I can always make them work.
    - pjmlp 5y ago
      Yeah I remember those happy days. There were some configuration behaviours on the standard that had opposite defaults.
- pjmlp 5y ago
  Agreed, but unfortunately so is fashion in this industry.
- atombender 5y ago
  And there's Cap'n Proto, which is essentially a reinvention of CORBA. Unlike gRPC, where RPC calls are just functions that take pure data arguments and return pure data structs, Cap'n Proto allows RPCs to return references to objects. The client can hold onto the reference and call methods on it, which invoke RPC calls, while the client and server runtimes keep track of what the references refer to. So you can treat remote objects as if they're local to your process. This "location transparency" feature is at the heart of CORBA, and later, Microsoft DCOM and Java RMI. I've never used Cap'n Proto, but with CORBA/DCOM/RMI, this is a really powerful feature which allows you to work with APIs as if they're just in-process libraries. The downside is that if you pretend there's no network overhead, you might end up designing very inefficient applications, with each method call becoming a network roundtrip. It also means a client can, if you're not careful, "hog" a remote object and keep it from being deallocated, resulting in leaks or excessive memory usage. Basic DCE-style RPC like gRPC is simpler and has more predictable performance, since you're forced to consider that you're talking to a remote API, just like REST.
  - codr7 5y ago
    Having worked with some of those; I'm going to say thanks, but no thanks. Hiding network access and pretending it's all local is a recipe for disaster. If you're writing a networked application, that's right up there on the list of things you need to focus on and never forget.

Unpopular opinion: CORBA was underrated. For its time, CORBA was a decent way of stitching together heterogeneous systems. Tediously hand-coding REST APIs was a big step backwards, and gRPC is really just catching up to where we were before.

poulsbohemian 5y ago
Thank you!! I did my undergrad thesis around CORBA (showing my age…) and you are spot on that the whole world proceeded to pile on a whole lot of work in order to make everything run over http.
scrumper 5y ago
I remember learning about CORBA in undergrad too. Then a few months into my first job, "new guy, go do this integration with SOAP/WSDL." Crushed me so hard I went into sales.
- AnotherGoodName 5y ago
  The 'never again' part of working with soap for me was that Microsofts and Javas soap libraries were more or less incompatible for a variety of reasons. I could handle the xml madness but at least make sure the standard is a standard. I'm pretty happy with rest apis on that front. I can always make them work.
  - pjmlp 5y ago
    Yeah I remember those happy days. There were some configuration behaviours on the standard that had opposite defaults.
pjmlp 5y ago
Agreed, but unfortunately so is fashion in this industry.
atombender 5y ago
And there's Cap'n Proto, which is essentially a reinvention of CORBA. Unlike gRPC, where RPC calls are just functions that take pure data arguments and return pure data structs, Cap'n Proto allows RPCs to return references to objects. The client can hold onto the reference and call methods on it, which invoke RPC calls, while the client and server runtimes keep track of what the references refer to. So you can treat remote objects as if they're local to your process. This "location transparency" feature is at the heart of CORBA, and later, Microsoft DCOM and Java RMI. I've never used Cap'n Proto, but with CORBA/DCOM/RMI, this is a really powerful feature which allows you to work with APIs as if they're just in-process libraries. The downside is that if you pretend there's no network overhead, you might end up designing very inefficient applications, with each method call becoming a network roundtrip. It also means a client can, if you're not careful, "hog" a remote object and keep it from being deallocated, resulting in leaks or excessive memory usage. Basic DCE-style RPC like gRPC is simpler and has more predictable performance, since you're forced to consider that you're talking to a remote API, just like REST.
- codr7 5y ago
  Having worked with some of those; I'm going to say thanks, but no thanks. Hiding network access and pretending it's all local is a recipe for disaster. If you're writing a networked application, that's right up there on the list of things you need to focus on and never forget.