El actor model: el modelo de Hewitt

Mucho antes de que existiera un solo framework de estado, en 1973 Carl Hewitt formuló una pregunta radical: ¿y si la unidad mínima del cómputo no fuera el objeto ni el hilo, sino una entidad viva que no comparte absolutamente nada con las demás y solo se relaciona enviando mensajes? Esa entidad es el actor. El modelo que lleva su nombre no es una librería ni un patrón de diseño: es una teoría de la concurrencia, y es el suelo conceptual sobre el que XState v5 construye todo. Entenderlo aquí, en abstracto, hará que cada API del nivel te parezca inevitable en lugar de arbitraria.

Un actor: tres capacidades

Hewitt redujo la concurrencia a una figura y tres verbos. La figura es el actor: una entidad con estado privado y un comportamiento. Los tres verbos describen todo lo que un actor puede hacer al recibir un mensaje, y absolutamente nada más está permitido. No hay una cuarta operación escondida, y esa parquedad es deliberada.

La fuerza del modelo está en lo que prohíbe. En el mundo de objetos e hilos, dos hilos pueden leer y escribir el mismo campo a la vez, y de ahí nacen las condiciones de carrera. Un actor no ofrece esa posibilidad: su estado es inaccesible desde fuera. La única manera de pedirle algo es depositar un mensaje en su buzón y esperar. La designación de comportamiento sustituye a la asignación compartida: en lugar de que otro escriba en tu memoria, tú decides qué harás con lo que llegue.

El tercer verbo es el más sutil y el que más nos costará reconocer luego en XState. Mutar el estado, en el modelo puro, no es asignar a una variable: es designar el comportamiento con el que se atenderá el próximo mensaje. Un actor no cambia un campo; se convierte en una versión de sí mismo que responderá distinto. Esa reformulación, que parece un rodeo, es lo que mantiene la mutación encerrada dentro de la frontera del actor.

// Designar comportamiento: el actor decide como respondera al SIGUIENTE mensaje.
// No muta memoria ajena; reemplaza su propia funcion de recepcion.
function cuentaAtras(restantes: number) {
  return (msg: { tipo: "tic" }, self: Actor) => {
    if (restantes === 0) return convertirse(self, terminado)
    console.log(restantes)
    return convertirse(self, cuentaAtras(restantes - 1))  // nuevo comportamiento
  }
}

El actor frente al objeto y al hilo

Para situar el modelo conviene contrastarlo con las dos abstracciones que todo programador ya conoce. Un objeto encapsula estado, pero lo expone por métodos síncronos: quien tiene una referencia entra en su memoria y la lee o la muta en el acto, en el mismo hilo. Un hilo introduce ejecución concurrente, pero comparte memoria con los demás hilos, y de ahí nacen los candados. El actor toma lo bueno de ambos y descarta lo peligroso: encapsula estado como el objeto, corre concurrentemente como el hilo, pero no expone su memoria ni la comparte con nadie.

La fila de la comunicación lo decide todo. La llamada a método acopla en el tiempo —el que llama espera— y en el espacio —ambos comparten hilo—. El mensaje asíncrono rompe los dos acoplamientos: el emisor no espera y no necesita estar en el mismo lugar. Esa doble ruptura es lo que permite repartir un programa de actores entre núcleos o entre máquinas sin cambiar su lógica, algo que ni objetos ni hilos consienten sin reescribirse de raíz.

Aislamiento y el buzón: por qué no hay carreras

Cada actor posee un buzón privado —una cola— donde sus mensajes se acumulan. El actor los procesa de uno en uno, secuencialmente. Esta serialización es la clave: como solo se atiende un mensaje cada vez y el estado nunca se comparte, dos operaciones jamás pisan el mismo dato al mismo tiempo. La condición de carrera no se evita con disciplina ni con candados; sencillamente no puede expresarse.

// Un actor en pseudocodigo: estado privado y un buzon que procesa de a uno.
type Mensaje =
  | { tipo: "incrementar" }
  | { tipo: "leer"; responder: Actor }

function contador() {
  let valor = 0                         // estado privado, invisible desde fuera
  return (msg: Mensaje) => {             // se procesa un mensaje cada vez
    if (msg.tipo === "incrementar") valor += 1
    if (msg.tipo === "leer") enviar(msg.responder, { valor })
  }
}

Fíjate en el mensaje leer: no devuelve el valor con un return, sino que incluye la dirección de otro actor al que responder. En el modelo puro no existe la lectura síncrona; incluso preguntar es enviar un mensaje y esperar la respuesta en tu propio buzón. Esa asimetría, que al principio incomoda, es lo que permite que el actor que pregunta no se quede bloqueado esperando a otro.

flowchart LR
M1[mensaje 1] --> Q[buzon]
M2[mensaje 2] --> Q
M3[mensaje 3] --> Q
Q -- de uno en uno --> AC[actor procesa]
style Q fill:#f9e2af,color:#11111b
style AC fill:#cba6f7,color:#11111b

Un runtime de actores no es más que un bucle que saca mensajes del buzón y aplica el comportamiento actual a cada uno. En pseudocódigo cabe en unas líneas, y deja ver que no hay magia: solo una cola, un estado privado y una función que se aplica de a un mensaje.

// Un micro-runtime: crear un actor, encolar mensajes y procesarlos en orden.
function crear(comportamiento: Comportamiento) {
  const buzon: Mensaje[] = []
  const self = {
    enviar(msg: Mensaje) {           // depositar en el buzon, nunca ejecutar ya
      buzon.push(msg)
      planificar()
    },
  }
  function planificar() {
    queueMicrotask(() => {
      while (buzon.length) comportamiento(buzon.shift()!, self)  // de a uno
    })
  }
  return self
}

Transparencia de ubicación y supervisión

Un actor no conoce a otro por un puntero a su memoria, sino por una dirección: un identificador opaco al que enviar mensajes. Esa dirección no revela si el actor destino vive en el mismo hilo, en otro núcleo o en otra máquina al otro lado de la red. A esa propiedad se le llama transparencia de ubicación, y es lo que permite que el mismo código escale de un hilo a un clúster: enviar es siempre asíncrono, tanto si el destino está al lado como si está lejos.

flowchart LR
A[actor A] -- mensaje --> B[actor B]
A -- crea --> C[actor C]
B -. respuesta asincrona .-> A
C -- mensaje --> B
style A fill:#89b4fa,color:#11111b
style B fill:#cba6f7,color:#11111b
style C fill:#a6e3a1,color:#11111b

De la capacidad de crear actores surge la supervisión. Como el creador conoce la dirección de sus hijos, puede vigilarlos: si uno falla, el padre recibe la noticia y decide reiniciarlo, ignorarlo o propagar el fallo hacia arriba. Erlang convirtió esta idea en su lema —let it crash, déjalo fallar— y construyó sistemas de telefonía con años de disponibilidad sobre ella. El fallo de un actor queda contenido: no corrompe la memoria de sus hermanos porque no hay memoria común que corromper.