> Hello!
> I am learning Erlang and really liking it.
Great
> I am finding myself really liking the immutability in regards to being able to reason about my code, but that leaves me with a probably easy question: why does immutability make concurrency easier?
Tricky I guess it makes parallel execution easier (no locks) - it certainly makes programming easier closures really are closures :-)
> Is it because it's difficult to have something in a thread reach-across and modify the state of another thread?
That's not really immutability - actually I hate threads - the difference between a thread and a process is crucial - threads can modify shared state (horrible) -
In distributed systems there is no real shared state (imagine one machine in the USA another in Sweden) where is the shared state? In the middle of the Atlantic? - shared state breaks laws of physics. State changes are propagated at the speed of light - we always know how things were at a remote site not how they are now. What we know is what they last told us. If you make a software abstraction that ignores this fact you'll be in trouble.
> Does that mean concurrency wouldn't be so bad if you kept state mutations contained within one thread?
Yes - if you use the word process, not thread. Processes were invented to provide protection from other computations and to share resources in a clean way - threads share resources in a messy way.
> If you don't have time to answer right now, a link or some guidance into the right resource would be appreciated! I think what you're interested in is the distinction between message-passing-concurrency and shared-memory-concurrency.
Java/C++/etc uses shared-memory concurrency (evil) - Erlang uses message passing concurrency.
AS Alan-Kay said - the big thing about OO is message passing not all the other stuff ...
> > I love Erlang, and I appreciate you reading my message!
Have fun
/Joe