BEAM Concurrency in Action • Sasa Juric • YOW! 2022

[@marianouvalle895]

Sasa never disappoints! Thanks for this very clear and informative talk.

[@wargreymon2024]

This is very clear, and I am liking Beam more.

[@ankk98]

Elixir & beam are really interesting. I will have to do some projects in it to actually grasp it.

[@steholto]

Concurrent in action is a good name for a book by Sasa Juric

[@viktorshinkevich3169]

13:17 I think one abstraction for both CPU and IO bound tasks is the superpower here! Just like in Golang, with Go routines, you dont care if its one or another. Colored functions is not a problem and its beautiful.

[@akemegbebu7807]

The cancelation feature is so simple but has far reaching implication. Try to do the same in scala or go.... This is amazing

[@somosworld]

He actually (very casually) described how go-lang handles cancels. Via context that is passed from function to function. Not nearly as elegant. With scala, well good luck.

[@viktorshinkevich3169]

15:23 another lovely thing here in elixir is that this "new state" is not somehow implicit inner value, but rather an input argument that explicitly passed in the loop(new_state) function call.

[@straight-out-of-camera]

this is functional programming

[@viktorshinkevich3169]

@@straight-out-of-camera and it’s so lovely

[@ankursatle]

So, manage tasks as processes and allow OS to clean-up naturally. Seems like a clean way. Do messages exchanged go through kernel space facilities and with system mutual exclusion? Does this introduce greater lag? You commented about cooperative cancellation. I would like to contrast your approach and cooperative cancellation: Your pid-based approach: 1. You need to hold on to the pid for the query-id; 2. Cancellation needed further handling for clean-up and side effects. Cooperative cancellation: 1. You need to hold on to the cancellation token for the query-id; 2. Cooperative cancellation cleaned-up after itself and eliminated side-effects. Both sound similar and no less or more hassle than the other. The place of implementation of clean-up seems different. I am happy to be corrected and learn.

[@iamhardliner]

One of the big benefits of the actor model is, that you can do all your scheduling in user-space. So messages do not need to go through the kernel at all, which makes it more efficient than similar algorithms using threads.