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

41–50 of 156 posts

Re: The Rise and Fall of CORBA (2006)

#41

Post by littlecranky67 »

lelanthran wrote: post #29
winrid wrote: post #7

Earlier quoted context omitted.

Why no type checking? Generate an Open API client for target languages. Done. Assuming you need an API. I'll never build an app that way again, it's not worth my hands. I'd rather use Hotwire, or LiveViews, or Django's Unicorn for the web part. Zod looks nice too.

> Why no type checking? Generate an Open API client for target languages. I dunno. Why aren't more people using openapi? What I see in practice is that almost everyone is using JSON as the transport mechanism and not generating that JSON serialisation code from open API specs. The type-checking in CORBA was not opt-in, it was mandatory. Type-checking in browser fetch() calls are optional. To opt-in you have to go out…

From my experience, code generators arent stable and reliable enough. Whenever I was in a project where either side (Backend/Frontend) generated code from OpenAPI/Swagger spec, they broke at some point - weeks after introducing, by using some new feature/syntax in the specfile.

Given that they produce human unmanageable/readable code, ejecting was a terrible solution.

Re: The Rise and Fall of CORBA (2006)

#42

Post by danmaz74 »

jiggawatts wrote: post #33
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.

A huge influx of “programmers” that knew only JavaScript and thought that HTTP is the only network protocol, that’s why. But seriously, the root cause of the regression is the web and its associated limitations, quirks, and bad habits. For example, many web developers started out with eval() and maybe JSON which they thought was simple because it is text based and can be interactively experimented with in the browser…

You can mock the "moving fast" trope, but the truth is that moving fast has actually been very important for most web-related software development since the beginning. The reason is that the web is a super-competitive environment where the speed of experimentation and adaptation wins most of the time - even if we, as engineers, might not like that.

Re: The Rise and Fall of CORBA (2006)

#43

Post by whizzter »

lelanthran wrote: post #29
winrid wrote: post #7

Earlier quoted context omitted.

Why no type checking? Generate an Open API client for target languages. Done. Assuming you need an API. I'll never build an app that way again, it's not worth my hands. I'd rather use Hotwire, or LiveViews, or Django's Unicorn for the web part. Zod looks nice too.

> Why no type checking? Generate an Open API client for target languages. I dunno. Why aren't more people using openapi? What I see in practice is that almost everyone is using JSON as the transport mechanism and not generating that JSON serialisation code from open API specs. The type-checking in CORBA was not opt-in, it was mandatory. Type-checking in browser fetch() calls are optional. To opt-in you have to go out…

We use OpenAPI/Swagger specs whenever possible for new projects and integrations (some usages or integrations are older).

Generating a OpenAPI/Swagger spec in .NET is as easy as telling a lib like NSwag to generate and publish documents from your API's (and you can filter out to only show public API's in the docs). Probably as easy in Java,go,etc.

Consuming services can usually be done almost as easily by downloading the spec and pointing a code-generator to it.

HOWEVER the mandatory vs opt-in part is why we are stuck with JSON based api's, consuming/providing the typings becomes extra work when interfacing/playing with an API from any dynamic language such as JS, Python, Ruby, etc whilst you really only pay a relatively minor performance penalty from typed languages that people won't care about in dev up until it hits in production (Assuming you have an modern JSON serializer library built for speed).

Anything resembling "bloat"/complexity (sadly types is in this category from the perspective of many anti-TS JS developers, esp as API-typings still won't come from the host language but having to be provided separately) will be offputting and lead to any such spec being ignored by a substantial chunk of developers.

Re: The Rise and Fall of CORBA (2006)

#44

Post by MichiHenning »

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.

Re: The Rise and Fall of CORBA (2006)

#45

Post by discreteevent »

danmaz74 wrote: post #42
jiggawatts wrote: post #33

Earlier quoted context omitted.

A huge influx of “programmers” that knew only JavaScript and thought that HTTP is the only network protocol, that’s why. But seriously, the root cause of the regression is the web and its associated limitations, quirks, and bad habits. For example, many web developers started out with eval() and maybe JSON which they thought was simple because it is text based and can be interactively experimented with in the browser…

You can mock the "moving fast" trope, but the truth is that moving fast has actually been very important for most web-related software development since the beginning. The reason is that the web is a super-competitive environment where the speed of experimentation and adaptation wins most of the time - even if we, as engineers, might not like that.

I disagree. From what I observed it speeded up developers for about two months and then they started to get stuck in their own webs.

Re: The Rise and Fall of CORBA (2006)

#47

Post by hackandthink »

"In the early ’90s, persuading programs on different machines to talk to each other was a nightmare ... (Other early middleware, such as Sun ONC... was tied to C and Unix and not suitable for heterogeneous environments.)"

I disagree here. SUN RPCs (ONC) based on XDR worked well and were quite enjoyable to use.

CORBA was victim of the Second-system effect.

And CORBA meant C++ in the early 90ies. Memory management was a nightmare, C++ and CORBA Apis don't go well together.

https://en.wikipedia.org/wiki/Sun_RPC https://en.wikipedia.org/wiki/External_Data_Representation

Re: The Rise and Fall of CORBA (2006)

#48

Post by whizzter »

littlecranky67 wrote: post #41
lelanthran wrote: post #29

Earlier quoted context omitted.

> Why no type checking? Generate an Open API client for target languages. I dunno. Why aren't more people using openapi? What I see in practice is that almost everyone is using JSON as the transport mechanism and not generating that JSON serialisation code from open API specs. The type-checking in CORBA was not opt-in, it was mandatory. Type-checking in browser fetch() calls are optional. To opt-in you have to go out…

From my experience, code generators arent stable and reliable enough. Whenever I was in a project where either side (Backend/Frontend) generated code from OpenAPI/Swagger spec, they broke at some point - weeks after introducing, by using some new feature/syntax in the specfile. Given that they produce human unmanageable/readable code, ejecting was a terrible solution.

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 ambigious mappings when it then comes to the frontend (Typescript) side, the Typescript side then mostly benefits from client-side typings for developers but actually validating isn't always done if we only have SPA consumers (Incompatible upgrade -> new cloned endpoint for the duration of the upgrade period).

Re: The Rise and Fall of CORBA (2006)

#50

Post by jiggawatts »

danmaz74 wrote: post #42
jiggawatts wrote: post #33

Earlier quoted context omitted.

A huge influx of “programmers” that knew only JavaScript and thought that HTTP is the only network protocol, that’s why. But seriously, the root cause of the regression is the web and its associated limitations, quirks, and bad habits. For example, many web developers started out with eval() and maybe JSON which they thought was simple because it is text based and can be interactively experimented with in the browser…

You can mock the "moving fast" trope, but the truth is that moving fast has actually been very important for most web-related software development since the beginning. The reason is that the web is a super-competitive environment where the speed of experimentation and adaptation wins most of the time - even if we, as engineers, might not like that.

The problem is that the "fast" part is in quotes because it's glacially slow as soon as you get past the initial MVP or demo.

I see this idiocy everywhere, to the point that many clouds are now advertising "Day 2 operations" like it's a new thing to be doing things for more than one day.

Everywhere you turn, it's: "Get started quick", "Quickstart", "Deploy to !", etc...

What do you do after deployment is... crickets chirping, wolves howling, and a tumble weed rolling slowly past.

CORBA, Java Remoting, .NET WCF, WS-*, etc... are complex technologies that can't be trivially poked and prodded with curl or a repl. What they provide is tooling and long-term velocity and safety even with hundreds of developers on the team.

Heck, even as a solo developer I strongly favoured the "proper" RPC systems. I could define a class type once, and then Visual Studio or IDEA or whatever would spit out tens of thousands of lines of error-free boilerplate code that otherwise I would have to hand-roll.

You can't imagine how depressed it makes me when I see some Web API guide that starts off with a cheery "this is a simple..." and then there's five hundred pages of English text.

Look. Sure, if you're an Indian outsourcer developer, this is great. You can bang out monotonous repetitive code like a meat robot and collect a pay check your subsistence farmer parents could only dream of. You can do this for years, and never have to think, or be creative, or risk your job security.

But people that need to get things finished, past day two into day five hundred? We use the good stuff, with automation.

Half the world still builds roads with hand tools. Where I live, we build roads with heavy machinery.

That's the difference. Any idiot can pick up a hammer and say "road building is easy". They'll still be building that road with an army of workers a year later.

Post reply on HN