Hacker News new | past | comments | ask | show | jobs | submit login

I'm arguing that the semantics aren't that different. Callbacks (such as used in Node and in libevent/libev-based async programs, as I said I don't really know gevent) and Erlang's process model both depend on individually dispatched messages to communicate events that are often fine-grained in nature: connection accepted, bytes received from buffer, failure occurred, child process died, name resolution completed, etc. This necessarily fragments the logic by requiring that each event be handled pieacemeal, either in separate callbacks or, in Erlang's case, often using pattern matching. I am arguing that the way you code these "callbacks" is superficially similar both in Erlang and in other async systems, and that the patterns, challenges, etc. are very similar, even though Erlang usually outcompetes the alternatives in terms of power and richness.



I really so very little similarity between how Erlang handles this communication and Node. Erlang processes communicate that events happen, sure. But resulting code has almost zero similarity to that of Node. Individual paths of execution don't even exist in Node since everything is jumbled together. Relating a callback to a pattern match is a rather naive comment.


You are still missing my point. Event-oriented code necessarily becomes non-linear and fragmented, with logic weaving in and out of event handlers, as supposed to classic synchronous, sequential code. This applies to any system based on "callbacks" — ie., asynchronous event handling — including Erlang.


No it doesn't. I can handle just those events that are relevant to the series of states I care about in order in Erlang. I can also toss them into another process. Interleaving is not required in Erlang.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: