Comment by mort96 | Hacker News Reader

Comment by mort96 | Hacker News Reader

Parent Full thread

Frankly, I completely disagree. There was a lot of research into distributed objects back in the 80s/90s; languages which allow objects to seamlessly move between nodes. And there's a very good reason IMO why that never took off. Communication between processes is always fallible and subject to blocking indefinitely, and when such communication happens implicitly and all over the place, the result is a disaster. IPC must be explicit, not implicit.

IPC must also be language-agnostic, which means serialization and deserialization, which means there will always be some manual "impedance matching" between your program's domain model and the IPC protocol's messages.

Could things be better? Sure, yeah, I guess. Languages with a single implicit event loop and with native support for JSON-like trees of values (such as JavaScript) will have an easier time than languages with neither (such as C++). But I don't think there's really some magical 10x better solution out there if only we had all "seen the light" and used SmallTalk.

> Communication between processes is always fallible and subject to blocking indefinitely

You speak as if you have never heard of Carl Hewitt's research, Erlang or Elixir before.

Or Java RMI, Jini, .NET Remoting, Tcl agents, or many others with similar approaches.

You mentioned SmallTalk, not Erlang.

I wasn't aware that Erlang did IPC implicitly.

Erlang puts communication across actors/processes at its core mechanism. Sending a message is as simple as adding two numbers. It is closer to Smalltalk than a lot of other programming paradigms.

The real issue is that Erlang is its own world. But you could also say IPC is its own world (does not work natively on the Internet, does not work on non-UNIX machines, etc.)

Erlang is being sneaky because an Erlang "process" is not the same thing as what the rest of call us a "process". As soon as Erlang needs to talk across real processes is runs into all the same problems. Now, admittedly, Erlang has a nice supervisor toolkit to help with this, but its still a real problem, even for Erlang.

"Real processes".

The point is UNIX is too low-level for communication primitives. Maybe it's time to research new paradigms? It's been 60 years.

Okay but then you're talking about designing a completely new kind of kernel which has a completely different concept of what a "process" is, which is quite far away from "we should've just used SmallTalk".

Besides, no matter how you design the system, there will be a categorical difference between communication which is expected to be fallible and communication which is expected to be infallible. The "communication" between a caller and a callee is expected to be infallible, for example. Communication between threads in a process (in the UNIX and Windows model) is expected to be infallible.

Communication between an app and a system service is expected to be fallible; at the very least, the system service has to expect that the app might misbehave in any number of ways, even if you argue that the app should expect the system service to be perfect.

Depends pretty much how those threads were started.

In Windows there are fun things like COM apartments, owner module scopes, local RPC, wrapping in-proc COM into DCOM remoting.

Apple and Google have similar local RPC features coupled with multithtreading.

I don't understand what you think depends on how threads were started.

An HN comment is not big enough to explain OS specific threading models across component systems, and dynamic libraries.

Reply on news.ycombinator.com