3 ms·

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 betwe

by mort96 2y ago

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.

sph 2y ago
> 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.
- mort96 2y ago
  You mentioned SmallTalk, not Erlang. I wasn't aware that Erlang did IPC implicitly.
  - sph 2y ago
    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.)
    - grandinj 2y ago
      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.
      - sph 2y ago
        "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.
        mort96 2y ago
        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.
        pjmlp 2y ago
        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.
        mort96 2y ago
- pjmlp 2y ago
  Or Java RMI, Jini, .NET Remoting, Tcl agents, or many others with similar approaches.

by mort96 2y ago

sph 2y ago

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

mort96 2y ago
You mentioned SmallTalk, not Erlang. I wasn't aware that Erlang did IPC implicitly.
- sph 2y ago
  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.)
  - grandinj 2y ago
    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.
    - sph 2y ago
      "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.
      - mort96 2y ago
        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.
        pjmlp 2y ago
        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.
        mort96 2y ago
pjmlp 2y ago
Or Java RMI, Jini, .NET Remoting, Tcl agents, or many others with similar approaches.