4 ms·

It's what we did in C in the 80s and 90s and all the young hipsters chose to ignore. This industry loves going in circles. In the same vein, I also heard that

It's what we did in C in the 80s and 90s and all the young hipsters chose to ignore. This industry loves going in circles. In the same vein, I also heard that the new data exchange hotness is grpc. Reading a little into that thing it sounds very much like the good, old... CORBA. So many wheels reinvented every decade, sigh.

antonvs 4y ago
Many of the reasons CORBA failed are the reasons that gRPC is succeeding. CORBA tried to solve the wrong problem at the height of the object orientation fad - it tried to provide a standard mechanism for remote “objects” across languages which have different object semantics. It was a doomed idea from the start. As for the industry going in circles, it only looks that way if you’re not familiar with the technologies in question. The idea that statically linked binaries are an alternative to containers doesn’t make any sense. In fact, it’s not that uncommon for a container to contain nothing but a statically linked binary. People don’t do that for fun, they do it for the additional features and standardization it provides over a standalone binary.
- zozbot234 4y ago
  Distributed objects had nothing to do with object semantics in a PL. They're a lot closer to what we would now refer to as the actor model.
  - antonvs 4y ago
    > Distributed objects had nothing to do with object semantics in a PL. In a way, that was the problem. In practice for CORBA, there was a problematic relationship between its object model and the object models of its host programming languages. CORBA was supposed to be language independent, but that meant that native language objects and CORBA objects weren't the same thing. There was a semantic gap, analogous to the one between relational databases and object-oriented languages. In the latter case, you can use an ORM-like solution or even just handwritten data access objects to achieve a native language object layer for your data model. With CORBA, that wasn't really feasible - you had to embed CORBA object implementations in your language of choice, and program to that non-native object model. In some ways it's comparable to .NET, but that has the advantage of using a common underlying runtime across all its language implementations. CORBA didn't have that. You mention the actor model, but what examples are there of successful cross-language actor implementations? The reason for this is exactly what I'm talking about. The practical consequences of a cross-language distributed object model are problematic. The closest answers I'm aware of share a common runtime - there's Erlang and Elixir both on the Erlang BEAM runtime, and Akka with Java and Scala on the JVM, with variants for C# that I'm not too familiar with. In both cases, the common runtime determines the shared semantics of the object model, so you don't get the same kind of semantic gap. It's not a coincidence that what's ended up becoming popular are data-only formats like JSON and service-oriented RPC mechanisms like gRPC or even REST - these don't conflict with native language structures in the same way. As I said, many of the reasons CORBA failed are the reasons that gRPC is more successful - the most critical one being that's CORBA's notion of "object" was the wrong level of abstraction for language-independent distributed computing.

antonvs 4y ago

Many of the reasons CORBA failed are the reasons that gRPC is succeeding. CORBA tried to solve the wrong problem at the height of the object orientation fad - it tried to provide a standard mechanism for remote “objects” across languages which have different object semantics. It was a doomed idea from the start. As for the industry going in circles, it only looks that way if you’re not familiar with the technologies in question. The idea that statically linked binaries are an alternative to containers doesn’t make any sense. In fact, it’s not that uncommon for a container to contain nothing but a statically linked binary. People don’t do that for fun, they do it for the additional features and standardization it provides over a standalone binary.

zozbot234 4y ago
Distributed objects had nothing to do with object semantics in a PL. They're a lot closer to what we would now refer to as the actor model.
- antonvs 4y ago
  > Distributed objects had nothing to do with object semantics in a PL. In a way, that was the problem. In practice for CORBA, there was a problematic relationship between its object model and the object models of its host programming languages. CORBA was supposed to be language independent, but that meant that native language objects and CORBA objects weren't the same thing. There was a semantic gap, analogous to the one between relational databases and object-oriented languages. In the latter case, you can use an ORM-like solution or even just handwritten data access objects to achieve a native language object layer for your data model. With CORBA, that wasn't really feasible - you had to embed CORBA object implementations in your language of choice, and program to that non-native object model. In some ways it's comparable to .NET, but that has the advantage of using a common underlying runtime across all its language implementations. CORBA didn't have that. You mention the actor model, but what examples are there of successful cross-language actor implementations? The reason for this is exactly what I'm talking about. The practical consequences of a cross-language distributed object model are problematic. The closest answers I'm aware of share a common runtime - there's Erlang and Elixir both on the Erlang BEAM runtime, and Akka with Java and Scala on the JVM, with variants for C# that I'm not too familiar with. In both cases, the common runtime determines the shared semantics of the object model, so you don't get the same kind of semantic gap. It's not a coincidence that what's ended up becoming popular are data-only formats like JSON and service-oriented RPC mechanisms like gRPC or even REST - these don't conflict with native language structures in the same way. As I said, many of the reasons CORBA failed are the reasons that gRPC is more successful - the most critical one being that's CORBA's notion of "object" was the wrong level of abstraction for language-independent distributed computing.