3 ms·

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 pr

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
      I don't understand what you think depends on how threads were started.
      - pjmlp 2y ago
        An HN comment is not big enough to explain OS specific threading models across component systems, and dynamic libraries.

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
    I don't understand what you think depends on how threads were started.
    - pjmlp 2y ago
      An HN comment is not big enough to explain OS specific threading models across component systems, and dynamic libraries.