4 ms·

Are the concepts described in the article the same as Erlang or Erlang/OTP, or is there more to it?

AndresNavarro 15y ago
I'm not very knowledgeable about either Erlang or Go. But from what I read, Erlang doesn't share objects between threads whereas Go does. This is a serious difference, because as the article mention you have to decide what to do if there are references from other threads. That's why the parallel with processes breaks in the case of Go. Cleaning up the resources of a share nothing (or little, and in a centralized place, see shared mem) process is easy and fast. Cleaning up the resources of a share most/everything thread... not so much.
- masklinn 15y ago
  But that's the point is it not? TFA's building patterns to try to implement in Go some of the most basic facilities of Erlang, and try to work around Go's misfeatures (such as default shared memory). So the concepts described in TFA do indeed already exist in Erlang.
  - AndresNavarro 15y ago
    Indeed. Erlang has this feature, I didn't intend to imply otherwise. What I meant was that this mechanism would be more difficult to implement in Go.
    - masklinn 15y ago
      > What I meant was that this mechanism would be more difficult to implement in Go. Well of course, since it needs to be implemented in the first place whereas Erlang provides it as part of its core features.
    - deleted 15y ago
      [deleted]
signa11 15y ago
> Are the concepts described in the article the same as Erlang/OTP, or is there more to it? seems to be identical to what already exists in Erlang. it is pretty easy, imho, to have an appropriately defined 'terminate' in a 'receive' clause, of an erlang process. on receipt of the said message, erlang process can exit out of the event-processing loop, thereby terminating the process. not sure why author thinks this is not present in Erlang. this is part of the core language, and has nothing to do with OTP, which is a framework built on top of the language. edit-1 : clarified OTP's role (or lack of it).
masklinn 15y ago
Not OTP, just Erlang processes (memory isolation) and process links (an apoptosis signal, though here it seems pretty limited, to killing a supervisor only whereas Erlang can propagate death signal quite arbitrarily, including from children to supervisors or to unrelated processes without the dying process having any knowledge of the link). I don't understand why TFA says this does not exist anywhere else (let alone suggest it could be implemented in Erlang when erlang already goes quite far beyond that)

I'm not very knowledgeable about either Erlang or Go. But from what I read, Erlang doesn't share objects between threads whereas Go does. This is a serious difference, because as the article mention you have to decide what to do if there are references from other threads. That's why the parallel with processes breaks in the case of Go. Cleaning up the resources of a share nothing (or little, and in a centralized place, see shared mem) process is easy and fast. Cleaning up the resources of a share most/everything thread... not so much.

masklinn 15y ago
But that's the point is it not? TFA's building patterns to try to implement in Go some of the most basic facilities of Erlang, and try to work around Go's misfeatures (such as default shared memory). So the concepts described in TFA do indeed already exist in Erlang.
- AndresNavarro 15y ago
  Indeed. Erlang has this feature, I didn't intend to imply otherwise. What I meant was that this mechanism would be more difficult to implement in Go.
  - masklinn 15y ago
    > What I meant was that this mechanism would be more difficult to implement in Go. Well of course, since it needs to be implemented in the first place whereas Erlang provides it as part of its core features.
  - deleted 15y ago
    [deleted]

signa11 15y ago

> Are the concepts described in the article the same as Erlang/OTP, or is there more to it? seems to be identical to what already exists in Erlang. it is pretty easy, imho, to have an appropriately defined 'terminate' in a 'receive' clause, of an erlang process. on receipt of the said message, erlang process can exit out of the event-processing loop, thereby terminating the process. not sure why author thinks this is not present in Erlang. this is part of the core language, and has nothing to do with OTP, which is a framework built on top of the language. edit-1 : clarified OTP's role (or lack of it).

masklinn 15y ago

Not OTP, just Erlang processes (memory isolation) and process links (an apoptosis signal, though here it seems pretty limited, to killing a supervisor only whereas Erlang can propagate death signal quite arbitrarily, including from children to supervisors or to unrelated processes without the dying process having any knowledge of the link). I don't understand why TFA says this does not exist anywhere else (let alone suggest it could be implemented in Erlang when erlang already goes quite far beyond that)