Why isn't the actor model used in the wild?

I am learning elixir, and I am looking everywhere but for some reason the… actor model isn’t used at all?

There’s no other processes aside from… endpoints and repos??

here there’s a bit more child processes but like… why isn’t there more??

I’d argue that’s already a lot and most of what a website / webapplication needs without knowing anything more about the business case.

1 Like

I dunno I’d think that more processes would be spawned for things like… properly verifying data or something… the akkoma repo hasn’t got that much either I thought elixir was about processes?

Why though? Processes and their communcation mean additional overhead. That overhead is useful where you need (failure) isolation, like e.g. between different requests being handled, but it’s not useful where that’s not the case, like within a single webrequest being handled.

1 Like

I hope we won’t go in circles here once again.

2 Likes

Actors in Elixir generally map to runtime subcomponents of the system, not business entities. So for example when using phoenix channels or live view every connected page is an actor that manages messages in and data out, but then the business logic processing on that data favors functional data patterns.

5 Likes

Isn’t it technically that the actor model is used under the hood?

So the actor model doesn’t apply for business logic?

yea, under the hood. :sunglasses:

Yea, the actor model is the engine, but you use the car to do business. :oncoming_automobile:

Here is a paper by Carl Hewitt, the author of The Actor Model - https://arxiv.org/vc/arxiv/papers/1008/1008.1459v8.pdf. I hope it sheds some light on this model of computation.

so it matters to isolate requests from each other… but not to isolate the logic inside the requests from cascading into the whole request failing? no like retries or anything like that? talking to an unreliable api? maybe a chatroom as a process?

In a recent Phoenix project that I’ve added no processes to myself yet:

ies> Process.list() |> length()
242

Ya, I’d say there’s a few under the hood :wink:

3 Likes

Check out this brief section of the docs.

2 Likes

That’s where the “where it makes sense”/“where you need isolation” part comes in. It requires domain knowledge to make that judgement call. No framework can make those decisions for you.

the TLDR (as far as I understand):

use actors to encapsulate mutable state (or face lock issues) nothing else

I’m sorry if I sound dumb but I’m just trying to grasp were this feature of the Erlang VM which keeps getting talked about but rarely used (on purpose?) Is for and where it’s right.

  1. Processes (the actors) are used plenty in every Phoenix project, it was just made invisible to you and for your convenience. For example: the DB repo is basically a pool of connections but each connection is held up by a single process.
  2. Each request is in a new process. If you have 50 currently active requests, you have 50 extra processes. If you have 2000 currently active requests then you have 2000 extra processes.
  3. Libraries like Oban (for background jobs) use processes pervasively.

Frameworks like Phoenix already make use of processes. From then on it’s on you if you want to use extra processes.

As others have said, don’t use processes to model logic. Use processes to model separate runtime entities (like a task that needs to download stuff from 3rd party API, for example).

No, they are used for other purposes as well. See above.

4 Likes

It’s used all the time. Elixir code can’t run outside of a process. Even just booting up a vanilla REPL ($ iex) spawns 60 processes.

I’m no expert on the topic and I would search this forum for discussion about it as there is a bunch.

The TL;DR is model your business domain in pure functions, then run those functions in processes. Many of your examples are correct, like yes, a chatroom would run inside its own process. If you’re using LiveView in Phoenix, every user connection is a process.

4 Likes

So calling a webhook would be a process?