Generalizable design patterns using actors - help?

Learning Questions & Discussions Resources Chat/Questions
,
1

I’m not a hugely experienced programmer, just a few years. So I’m looking for resources to learn about a topic but I can’t seem to find much out there. Maybe someone here can point me in the right direction, here’s the topic.

I can see that using actors makes a program more generalizable, meaning, it can be deployed across nodes more easily. But I have this inkling that I don’t know the high-level design patterns that make a program more generalizable (as in, the code is able to be changed without introducing unintended consequences).

It seems as though actors are an abstraction over the typical sequential, linear type, procedural programming that I’m familiar with. But I’ve yet to find someone or some resource that can say, “Here’s how it’s different, programming with actors and here’s how to take advantage of the abstraction.”

Are there different design patterns when programming only with actors?

If such design patterns are immature or lacking in some way, could such patterns be developed if perhaps these kinds of systems used distributed consensus to ensure each node knows the order in which each message was sent? I wonder if perhaps that’s an element to truly generalizable code that hasn’t been embraced yet (I, of course, don’t know, that’s just my intuition).

Does anyone have any good resources for me?

Maybe to give an example of what I mean I’ll try to describe a common problem in programming:

You’ll have a system that should behave in some way if it receives a certain input:

if input_A do response_A

that’s easy, but what if, in a particular context you want it to do something else?

if input_A do
  if context_X do response_B 
  else do response_A

I just have this feeling that this kind of arbitrarily complicated logic can naturally fall out of a simple abstract structure of self-interested actors, instead of explicitly coding it, but I don’t know how exactly to program that way. Am I making any sense?

I’ve been searching for “building generalizable program flow with actor model” or “abstracting logic with actors” and stuff like that but I’m not finding the kinds of answers I’m looking for. I mostly get articles and videos explaining what an actor model is, which isn’t helpful.

It’s frustrating because I have this intuition about what’s possible, but I can’t find any resource that can tell me how to get there. Do you sympathize with me? Do you feel the same way? Am I missing out on some big secret that every erlang programmer knows? Or am I just up in the night?

I guess what I’m trying to say is that in a procedural language unintended consequences of complex code is always a negative thing, it’s always a bug to be avoided since you as the programmer must manage everything explicitly. But it seems to me, with the actor model and the abstraction it provides, there should be a way to organize them to leverage those complex interactions to naturally and continually maintain the overall desired state of the system. I don’t think it’s magic, I just think we should be able to naturally harness that power in some way with this additional layer of abstraction. But how?

Anyway, thanks for your attention and any feedback you may have.

1 Like
2

While in OOP there are a lot of design patterns, in Erlang/Elixir we have MFA. But Higher order functions replace easily template/strategy patterns because You can pass the implementation. Being functional has also some advantages over OOP.

Otp is the design pattern around processes, a good resource is Designing for scalability with Erlang/OTP. It takes time to select the right behaviour in the right situation.

I always try to avoid the use of if, it can be replaced by pattern matching. It allows You to match something given many conditions. If is also a macro around case statement.

There are patterns around distribution, depending on which sides of the CAP theorem You want to have. But this is high level stuff :slight_smile:

I would advise You to look deep into Otp, It is IMHO the most enjoyable part to learn.

3 Likes
3

In fact since Lambda’s were introduced to Java, the latest conventions of implementing the strategy pattern is moving toward Lambda’s (i.e. Higher Order Functions) instead of the classic GoF patterns. It’s only in certain performance-critical scenarios that Lambda’s aren’t recommended.

I recommend checking out this article by Sasa Juric. The gist being that OTP and processes are for runtime behavior whereas modules, functions, and data structures are used for actual business logic expression.

The workflow that works for me is to model the system just using data and functions then figure out what sort of run-time behavior, persistence, and query requirements need to be implemented.

Say you have messages that need to be ordered, or serialized, that might indicate a need for a GenServer which has a mailbox with FIFO properties. This GenServer needn’t be the full implementation of the business logic like an Object would, it just needs to model which run time aspects need to be serialized. For example, say you’re building a File Management system, in OOP you might have a File object whereas in an OTP implementation you might have a GenServer model just the uploading behavior instead of the full File life-cycle including deletions, tagging, what-have-you.

OTP is essentially distilled design patterns that let actor-model computing behaviors work together. Things like Supervisors, GenServers, links, and process registration just consume the modules and functions during run-time.

5 Likes
4

Exactly…

In addition, I find this presentation a must-see

4 Likes
5

I tend to work in the opposite way.

First I look at the run-time behaviour the system should have/needs to do what it is supposed to do in a reasonable way. For example looking how the different parts should interact with each other and how I can use processes, or actors if you prefer to call them that :wink:, to get the right level of concurrency. Then I start thinking about the message between the processes, who communicates with who and what types of protocols they need. Then, finally, I start thinking about how to implement the various types of processes and we get into code.

I find this is the best way for doing anything more complex than a very simple, sequential system. It is much more difficult to take an inherently sequential system and try to extend it to make it concurrent/parallel. Once you have gone sequential you tend to have locked your thinking.

I will admit that I have a very concurrency oriented view of the world. Definitely totally environmentally corrupted. :smile:

9 Likes
6

In completion to the presentation:

The book is about F#, but much if it can be easily applied to Elixir.

2 Likes