Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Concurrency with Actors, Goroutines and Ruby (igvita.com)
18 points by afhammad on Oct 21, 2014 | hide | past | favorite | 1 comment



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...




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: