Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rise and Fall of CORBA (2006)

queue.acm.org

Post reply on HN
Print view View original

131–140 of 156 posts

Re: The Rise and Fall of CORBA (2006)

#131

Post by kentonv »

rektide wrote: post #94
stickfigure wrote: post #18

Earlier quoted context omitted.

We've finally come full circle with gRPC, which is basically a simplified CORBA. I went through the whole cycle, and while I don't exactly miss CORBA, I do wonder why it took us so long to get back to that baseline of functionality.

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 orien…

> 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)

Re: The Rise and Fall of CORBA (2006)

#132

Post by winrid »

littlecranky67 wrote: post #56
whizzter wrote: post #48

Earlier quoted context omitted.

Out of curiosity, what front/backend languages was involved in this? OpenAPI/Swagger has various functionality for supporting polymoprhism but this is usually where problems crop up in my experience due to the mismatch between how languages support it. In our setup, the server is usually C# and we restrict the API's to primitives, records/objects (without inheritance) and lists of the previous. None of this has ambig…

It was mostly TypeScript and C#. Stuff gets worse when you use a generated swagger specfile from code, and then try to feed this into any other generator. But when hand-writing openapi specs, there are a lot of features that are not understood by generator or lead to subtle bugs. Stuff like intersections, mixins (oneOf, allOf, anyOf, not), and union types (with named discriminators) are a thing in OpenAPI but kind of…

It helps a lot to keep your interfaces simple and flat. Probably too late for your project but I always advocate for this - then integrating with other systems and languages is much easier.

Re: The Rise and Fall of CORBA (2006)

#133

Post by HarHarVeryFunny »

bwanab wrote: post #115

It is being overlooked that one of the big impediments to CORBA was the literal cost of license from the vendors. They all wanted to make big bucks. It kind of reminds me of the early days of LISP and smalltalk. Venders were more interested in cashing in than spreading the technology. To be sure, for a big company it wasn't that huge, but when the Dot-com boom went bust and company's were trying to find ways to save…

There's TAO which is an open source CORBA implementation that works just as well as any of the commercial implementations. Nobody in their right mind would use CORBA for a new project of course.

Re: The Rise and Fall of CORBA (2006)

#134

Post by jodrellblank »

anthk wrote: post #125
jodrellblank wrote: post #90

Earlier quoted context omitted.

> " I subscribed to 'Object' magazine, and still recall one article breathlessly predicting that in the future bespoke development would become bunk as folks would just buy e.g. an Aircraft object off the peg and plug it into their application. " One drum I keep beating is that COM in Windows is amazing for scripting and interoperability between programs. Before PowerShell and "everything is an object [but you're stu…

>don't know what they're missing Maybe you don't kow what you are missing by just using pipes with small binaries for everything :)

Take the video player MPV, it can be controlled by sending commands into a named pipe, which is good, so you can control it from a Python script - but now instead of having a system-wide standard like COM where you have PyWIN32 which works with any COM object to any COM program and you call methods from the MPV documentation with Python numbers and strings, now you have to have a Python-to-MPV-JSON-Schema serializer in your code, and if you want to use C# you need a C#-to-MPV-JSON-Schema-serializer in your code. All you're really doing is triggering some code inside MPV - calling some library functions - but instead of a convenient system-wide standard way to do it, there's a different inconvenient non-standard way of doing it from every language to every program. Strictly worse.

Re: The Rise and Fall of CORBA (2006)

#135

Post by naasking »

lelanthran wrote: post #123
naasking wrote: post #99

Earlier quoted context omitted.

> A remote call fails, the error propagates up the call stack, and someone gets an error message. Uh-huh, but did the message actually get through? Can they safely just retry? These are very uncommon failure modes on local systems but very common on networked systems. Without a proper stateful abstraction beyond just "procedure call", like a promise, you can't address these failure modes properly. > In the rare case…

> Uh-huh, but did the message actually get through? Can they safely just retry? ... > The use of promises and await indicates a possibility of failure semantics that would otherwise not be apparent in the program's control-flow. They don't, though. They don't indicate if the message got through. They don't indicate if you can safely retry. Their failure mode is exactly as opaque or as transparent as synchronous calls…

> They don't, though. They don't indicate if the message got through. They don't indicate if you can safely retry. Their failure mode is exactly as opaque or as transparent as synchronous calls.

The promise is at the remote end. Promise resolution is idempotent, so retries always resolve to the same value. These are correct promise semantics as pioneered in the E language.

Re: The Rise and Fall of CORBA (2006)

#136

Post by webnrrd2k »

pjmlp wrote: post #126
webnrrd2k wrote: post #124

Earlier quoted context omitted.

COM was awesome tech! I wish we had an equivalent today. I did a ton of python-com projects for a big aerospace company in the late 90's and it was amazingly easy to get a lot of well-integrated functionality for little time and effort. Really sad that it's not more common now.

COM is the main Windows API since Longhorn ideas were redone as COM. It isn't going anywhere, even if the tooling keeps as clunky as ever.

Sorry, I wasn't clear in that post -- I'm on Linux, and I wish Linux had an equivalent tech.

Re: The Rise and Fall of CORBA (2006)

#137

Post by littlecranky67 »

winrid wrote: post #132
littlecranky67 wrote: post #56

Earlier quoted context omitted.

It was mostly TypeScript and C#. Stuff gets worse when you use a generated swagger specfile from code, and then try to feed this into any other generator. But when hand-writing openapi specs, there are a lot of features that are not understood by generator or lead to subtle bugs. Stuff like intersections, mixins (oneOf, allOf, anyOf, not), and union types (with named discriminators) are a thing in OpenAPI but kind of…

It helps a lot to keep your interfaces simple and flat. Probably too late for your project but I always advocate for this - then integrating with other systems and languages is much easier.

I fully agree with you. If you keep your API simple, reasons for code generators disappear and are quickly drafted by hand.

Re: The Rise and Fall of CORBA (2006)

#138

Post by tguvot »

webnrrd2k wrote: post #136
pjmlp wrote: post #126

Earlier quoted context omitted.

COM is the main Windows API since Longhorn ideas were redone as COM. It isn't going anywhere, even if the tooling keeps as clunky as ever.

Sorry, I wasn't clear in that post -- I'm on Linux, and I wish Linux had an equivalent tech.

not exactly same, but dbus

Re: The Rise and Fall of CORBA (2006)

#139

Post by tguvot »

inferiorhuman wrote: post #58
sirtaj wrote: post #38

Earlier quoted context omitted.

KDE tried and discarded CORBA in KOM/KParts well before GNOME got around to putting it in production. DCOP was a response to CORBA's complexity and fragility, and was almost "reinvented" in the form of DBUS.

Now there's a name I've not seen in a while. And, yeah, if memory serves CORBA worked well enough for Gnome but not KDE because the C++ story was not great. Whatever bindings being used were dependent on features not well supported by G++, templates being painfully slow to compile, etc.

if my memory serves me right, corba (if form of orbit) worked well enough for gnome because almost nothing used it.

kde in it's turn were heavily reliant on it (mico) for embedding and communication. but compilation was indeed painfully slow (i still remember never ending kde compiles in 99-2000) so they came up with dcop/kparts after having few drinks and deciding that they can do better

Re: The Rise and Fall of CORBA (2006)

#140

Post by tguvot »

MichiHenning wrote: post #44

We still don't have anything in common use that can do what CORBA could do. gRPC doesn't even come close. If you are interested in this type of technology, I recommend looking at ZeroC's Ice. https://zeroc.com It's CORBA with all the warts removed, and a lot of other useful stuff added.

iirc zeroc established by people who used to do corba and then decided that they can do it better.

i tried to use it in one of products i worked on a while ago, but licensing was cost prohibitive: $200k ( $500k ?) or few percent from sales

Post reply on HN