

Concurrency with Actors, Goroutines and Ruby - afhammad
https://www.igvita.com/2010/12/02/concurrency-with-actors-goroutines-ruby/

======
chao-
As someone who has been teetering on both the Ruby/Elixir fence and the
Ruby/Clojure fence, I have to admit to not looking close enough at Goroutines.
A glances left me feeling like they were an abstraction at the wrong level, at
least for the type of concurrency I want to write. But I'll have to take a
look in order to play with Agent. Does anyone have a favorite guide/overview
to Goroutines?

Beyond that, the big conceptual takeaway/conclusion for me was this line, and
which is definitely going in my quotes file:

 _" So, the question is not whether threads need to exist, but rather, whether
they actually make for the best high-level interface to write, test, and
manage code that requires concurrency, regardless of runtime."_

It reminds me of listening to JavaScript Jabber's episode with David Nolen on
ClojureScript and Om. Amidst discussion of how Om leverages ClojureScript's
immutability to have a performance advantage over standard React.js [0], there
was a discussion (admission?) that _" our immutable data structures, the
reason they’re so fast is because under the hood we do use mutation. That’s
why they’re so fast."_.

So to use Ilya's words as a template: Like threads, it isn't a question of
whether mutability needs to exist, but rather, whether it actually makes for
the best high-level interface to write, test, and manage code.

[0] Is it a slight one? I don't want to misspeak or oversell it. JSJ is
transitioning to a new site design that currently makes the transcript hard to
read and find the exact quote on performance: [http://devchat.tv/js-
jabber/107-jsj-clojurescript-om-with-da...](http://devchat.tv/js-
jabber/107-jsj-clojurescript-om-with-david-nolen)

