Concurrency in Go (or, Erlang done right)
docs.google.com
Concurrency in Go (or, Erlang done right)
1–10 of 16 posts
Re: Concurrency in Go (or, Erlang done right)
#2So 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!
Re: Concurrency in Go (or, Erlang done right)
#3I like go and erlang, but the title is a troll.. Nowhere in the presentation does it compare the pros and cons of the go approach to how erlang does things.
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.
Re: Concurrency in Go (or, Erlang done right)
#4Not logged in to Google so cant read. Why do public google docs links still need login?
Re: Concurrency in Go (or, Erlang done right)
#5Not logged in to Google so cant read. Why do public google docs links still need login?
That's weird. I am not logged into anything related to Google, but I can read the document at this link.
Re: Concurrency in Go (or, Erlang done right)
#6Not logged in to Google so cant read. Why do public google docs links still need login?
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.
Re: Concurrency in Go (or, Erlang done right)
#7Not 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
Re: Concurrency in Go (or, Erlang done right)
#8So 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!
> 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?
Re: Concurrency in Go (or, Erlang done right)
#9Erlang is actually done right for its use case. Hard to tell about Go yet...
Re: Concurrency in Go (or, Erlang done right)
#10I like go and erlang, but the title is a troll.. Nowhere in the presentation does it compare the pros and cons of the go approach to how erlang does things. 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 laughabl…
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.