Hacker News Reader

Comment by _0w8t | Hacker News Reader

The actor model is prized in the talk. Yet actor model is not functional. The problem is the message queue of each actor. It is an imperative storage and one can get all nasty problems of imperative code from apparently functional code patterns.

View on HN

You can build every actor like a miniature program, with its own imperative shell and functional core. In Erlang it's common to have various message handlers that are very imperative, but defer all complicated logic to pure functions that take part of the actor state and return a transformed state.

I've been doing more and more Elixir work, and one of the most important lessons I keep learning is to keep my 'actors' as simple as possible and put the complicated stuff in my 'bags of functions'. I generally try to treat my code as two completely separate layers: the code that does stuff, and the code that orchestrates/isolates all of it.

What I find fascinating is that, at least for me, using GenServers/Agents/Tasks has made this distinction much more obvious than it has been in other languages.

I've built horrifying systems that muddled things together, only to realize quite far in how much of a mess I made, but with my Elixir projects I usually realize what I've done pretty quickly, and I end up course-correcting earlier on.

Actor model is even worse, you have no gerentee of a response or error status

There aren't that many ways you can mess up a message queue.

What would a functional approach be?

Function composition

It depends on what is the goal. To take advantage of multicore for computations one can use explicitly parallel functional algorithms. To improve response under load one can do load balancing within application and schedule at the very top (shell level) several independent functional pipelines.

Reply on news.ycombinator.com