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

I'm getting into concurrency from living a calm life where blocking the main thread was a thing.

What are HNers experiences with different models for concurrency and inter-process communication? To me, something like go and clojures channels (actually CSP) combined with green threads seems like a really neat solution.




Or Erlang/Elixir, which I found simpler than Go (though that may be due to my experience with Erlang, and my tending to think in Erlang ways, and it not quite matching Go's). Certainly, the guaranteed immutability, better pre-emptive scheduling, supervision, easy distribution of processes across multiple nodes, and better process isolation meant I felt my code was more reliable than with Go.

EDIT: Since you didn't mention Erlang, just to give you a point of reference, Erlang message passing is directly between lightweight processes, rather than an intermediate channel like in Go. I've heard people reference it as files vs file descriptors, but for myself, I think of it architecturally. Go creates an abstraction for the message type, that is, create a channel for ~this~ kind of message, and pub/sub to it as needed, and you shouldn't have to care about who is subscribed to determine what channel to publish on (it's enough to say 'it's this kind of message, so it goes on this channel'). Erlang, on the other hand (and Elixir) send messages directly to different processes, no additional abstraction. As such, you end up thinking about who needs to communicate with who, and how best to do that. So by default, it's like having a channel with exactly one known listener. Of course, you can easily build a channel like behavior, by creating a process whose sole job is to collect messages, and determine how to federate them out to other subscribed processes. I prefer the Erlang way because oftentimes the level of abstraction Go gives is unnecessary (and sometimes even a source of bugs, where I did a poor job of defining my messages, and not thinking about who was listening to the channel meant that a process got a message that it should not have, because of another, similarly typed message that it should have; I needed two channels, but created only one), but when it's useful I can always easily build it in.




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

Search: