# Design goals
Get as much usability and speed as possible while keeping line count low. Aim for no footguns, ability to plug in
logic easily, and run near anywhere.

We are not building a new erlang/BEAM. Minimal feature set means spawning actor processes, not having supervisiors, lots of process
monitoring tools, prempting, etc.

## Actor model

An actor has:

    - An inbox:
        this is a mpsc channel that the runtime/router dumps messages into and the actor consumes when the runtime loads it

    - an outbox channel connection:
        this is a mpmc channel that is implemented by the runtime and router. Actors on this specific channel put responses and outgoing messages into this channel, to be routed to the given address.

    - a growable and mutable state:
        An actor owns some, from the runtime perspective, type erased bytes. The actor when processing messages can access its own state, but no other task can. This includes viewing.

    - a set of functions for processing messages:
        When the runtime loads the actor, it locks the inbox and attempts to process the messages therein.

## Runtime and Router

In order for an actor to consume and send messages, it is processed by a runtime. The runtime, in order to negotiate messages between
actors, possesses a router.

A runtime has:

    - An actor processing thread(s):
        the processor will mark an actor as busy, load its state and inbox, and begin consuming messages from the inbox. The number of messages consumed is determined by the runtime

    - A message router:
        the router is responsible for ensuring messages posted by actors get delivered to the appropriate inbox.