3 ms·
Sorry for the nitpicking, but: "One of the things that Go (and Erlang) got right was using channels as the main mechanism for synchronising and communicating b
by haspok 10y ago
Sorry for the nitpicking, but:
"One of the things that Go (and Erlang) got right was using channels as the main mechanism for synchronising and communicating between threads."
Erlang doesn't have threads and doesn't use channels either.
Erlang has lightweight processes, which might map onto OS threads (but user code has no control over this).
Erlang uses async communication which is always non-blocking (of course, you can emulate sync communication, the gen_server:call behaviour in the OTP library does that, for example).
Otherwise, spot on! :)
- zzzcpan 10y agoOnly Erlang got it right, not Go. And channels were not even invented for real life programming, they were just an easy notation for mathematicians. But an interesting thing about concurrency is that the Erlang myth is actually true, getting deeper into concurrency always leads to reinventing Erlang. The road typically goes from synchronous multithreaded applications to asynchronous single threaded to event loops to higher-order abstractions around events to wrapping them into killable process/context abstractions to adding message passing and to reinvented Erlang.
- codr4life 10y agoCool, just wanted to add that there's nothing wrong with reinventing Erlang either. We're all in the same boat, ideas are universal.