Skip to content

"one-off DSL" #20

@JohnMurray

Description

@JohnMurray

The actor model is, at it's most basic, a concurrency primitive in a similar vein as threads and future. However it seems that we always make a big todo about actor systems that we don't make with threads, futures, co-routines, etc.

It could be interesting to experiment with what it would look like to have short-lived, single-purpose actor systems. I believe these would be inherently local systems used or orchestrate potentially complex tasks. Imagine the following bit of (hypothetical code):

let result: Future<Result> = system.run<DataFetchActor>(FetchRequest {
    service: "geo_ip.service",
    continent: "NA",
    department: "shoes",
})

In this example, there are a few things happening:

  1. We're spawning an actor, DataFetchActor, and providing a message to process
  2. A Future<Result> is created representing the response (an ask here, maybe same as ask pattern support #19)
  3. We're allowing data to return outside of the actor system
  4. The actor is closing down after handling the one request.

The reason this could be useful is that DataFetchActor may go on to spawn children. Perhaps it downloads quite a bit of data and does some data-processing. The logic within the actor may be complex, but we're using actors to organize that complexity.

Thought Process - It should be cheap and easy to spawn actor systems similar to how it's cheap and easy to spawn threads or futures. This lowers the barrier for use, opens up additional usage patterns, and allows for easier mix/match of concurrency patterns that can be common in large applications.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    Status

    Icebox

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions