Concurrency in Go (or, Erlang done right)(docs.google.com)
docs.google.com
Concurrency in Go (or, Erlang done right)
https://docs.google.com/present/view?id=df36r82q_5gdq5gzth&pli=1
5 comments
I agree the title is misleading (I should also point out that this isn't my slide deck, but one done by Dmitry Vyukov).
> Since go has/needs mutexes
I'm not sure it's really fair to say Go needs mutexes, just that they are available for you if you need the performance.
> Since go has/needs mutexes
I'm not sure it's really fair to say Go needs mutexes, just that they are available for you if you need the performance.
One funny thing is that the counting example has a really simple and very fast solution in Erlang. Shove the counter into an ETS table and use ets:update_counter as the call to manipulate it.
So suddenly I need to worry about mutexs and two processes accessing the same data.
As an Erlang programmer that smacks of Erlang done wrong to me. I don't want shared access. With no shared access I can 'let it crash' and know that I have process isolation. This also means that OTP and my restart libraries will 'just work' Erlang For The Win! Go For The Gone!
As an Erlang programmer that smacks of Erlang done wrong to me. I don't want shared access. With no shared access I can 'let it crash' and know that I have process isolation. This also means that OTP and my restart libraries will 'just work' Erlang For The Win! Go For The Gone!
> So suddenly I need to worry about mutexs and two processes accessing the same data.
Only if you're implementing higher-level concurrency primitives and want to maximize performance.
Did you completely ignore the context in which mutexes were mentioned in those slides?
Only if you're implementing higher-level concurrency primitives and want to maximize performance.
Did you completely ignore the context in which mutexes were mentioned in those slides?
To be fair the slides never really makes any comparisons with Erlang instead just used an inflammatory title, so it is understandable if responses are a little hand-wavy. It just goes along given the level of discussion.
> To be fair the slides never really makes any comparisons with Erlang instead just used an inflammatory title, so it is understandable if responses are a little hand-wavy.
Totally true - the Erlang too-dumb-to-be-a-cheap-shot was unwarranted. There are responses already posted in this thread along the lines of "This doesn't have anything to do with erlang at all" and they're completely justified.
The comment I responded to was calling out specific details out of context and making silly comparisons from there. That's all.
Totally true - the Erlang too-dumb-to-be-a-cheap-shot was unwarranted. There are responses already posted in this thread along the lines of "This doesn't have anything to do with erlang at all" and they're completely justified.
The comment I responded to was calling out specific details out of context and making silly comparisons from there. That's all.
Erlang takes another approach to many of these problems of concurrency. But I don't think you can argue that one is right while the other is wrong. Rather, right and wrong depends on your perspective and view on things.
Also, I am not sure there is one solution that fits all problems. It depends on your problem what is easiest to use. I mostly program Erlang, but I am following along on the Go-path since it is an interesting language - a modern C is my view of the language.
Also, I am not sure there is one solution that fits all problems. It depends on your problem what is easiest to use. I mostly program Erlang, but I am following along on the Go-path since it is an interesting language - a modern C is my view of the language.
I actually prefer an actor-centric model vs a channel-centeric model. Don't know why, just makes more sense to me, and Go way might make more sense to others.
Erlang is actually done right for its use case. Hard to tell about Go yet...
Not logged in to Google so cant read. Why do public google docs links still need login?
Uploaded PDF here http://www.box.com/s/v6a66qg1sqyqyfu1jque
That's weird. I am not logged into anything related to Google, but I can read the document at this link.
There seems to be a weird policy in Google Docs of asking you to log in if it knows you were logged into a Google account before.
Turn on the incognito mode of your browser or clear the cookies and try again, it should not prompt you to log in.
Turn on the incognito mode of your browser or clear the cookies and try again, it should not prompt you to log in.
You only think that you are not logged in. But Google doesn't forget you and tracks your footprints everywhere.
Sometimes selective receive with erlang's pattern matching is really useful. How about erlang's supervision hierarchies and recovering from errors? Erlang's hot code upgrades on long-running systems to avoid any downtime?
Since go has/needs mutexes, it's laughable to say it's "erlang done right". It's nothing like erlang in that sense.