Más allá de la arquitectura: Svelte, los signals y los errores de Rust

Preguntar por la influencia de un lenguaje suele llevar a la respuesta equivocada, porque instintivamente buscamos herederos que se le parezcan y la herencia real casi nunca funciona así. Elm tuvo descendencia arquitectónica evidente en Redux, en The Composable Architecture y en el linaje de MVI, y esa parte de la historia se cuenta sola. Pero hay una influencia más silenciosa, más difícil de rastrear y probablemente más importante, que no viajó en forma de patrón sino en forma de expectativa. Evan Czaplicki publicó en 2015 dos textos breves, uno sobre errores de compilación pensados para humanos y otro sobre la idea del compilador como asistente en lugar de como juez, y en ambos defendía una tesis que entonces parecía casi frívola: que la experiencia de equivocarse forma parte del diseño del lenguaje y merece el mismo cuidado que la semántica. Un año después, el equipo de Rust rehacía por completo el formato de sus diagnósticos y citaba a Elm entre sus referencias. Diez años después, ningún lenguaje nuevo se atreve a presentarse en público con mensajes de error crípticos. Esa transformación no dejó ninguna biblioteca ni ningún patrón de diseño, no aparece en los diagramas de arquitectura y sin embargo ha ahorrado más horas de trabajo humano que cualquier otra idea de esta lección. Conviene estudiarla junto a otras dos herencias oblicuas, la del compilador que sustituye al runtime y la de los signals, porque juntas dibujan mejor el mapa de lo que realmente se transmitió.

El compilador como asistente

El argumento de fondo es que un mensaje de error es una interfaz de usuario y que, como toda interfaz, tiene un destinatario, un contexto de uso y un estado emocional asociado. Quien lee un error está bloqueado, suele tener poca información y necesita tres cosas en este orden: dónde está el problema, por qué el compilador cree que lo es, y qué puede hacer al respecto. Los compiladores tradicionales daban lo primero de forma aproximada, lo segundo en un vocabulario interno que describía el estado del verificador de tipos en lugar del problema del programador, y lo tercero jamás. Elm reorganizó la salida entera alrededor de esas tres preguntas: recortó el fragmento de código relevante, subrayó la región exacta, expuso el tipo esperado y el encontrado uno debajo de otro para que la diferencia se viera de un vistazo, y añadió una sugerencia redactada en lenguaje llano, a veces con un enlace a la explicación del concepto implicado.

-- TYPE MISMATCH ------------------------------------------- src/Main.elm

The 2nd argument to `map` is not what I expect:

23|   List.map String.length usuarios
                             ^^^^^^^^
This `usuarios` value is a:

    List Usuario

But `map` needs the 2nd argument to be:

    List String

Hint: Perhaps you wanted to extract the name first with a function like
`.nombre` before measuring its length.

La reforma de Rust adoptó la misma anatomía y la llevó más lejos en un punto donde Elm no había entrado. Los diagnósticos de rustc distinguen la etiqueta principal de las secundarias, numeran los errores para poder pedir una explicación extensa y, sobre todo, marcan algunas sugerencias como aplicables por máquina, de modo que una herramienta puede reescribir el código por ti. Esa última pieza cierra el círculo del argumento original: si el compilador ya sabe qué hay que hacer, obligar al humano a teclearlo es una descortesía innecesaria.

Vale la pena señalar qué hizo posible ese cuidado, porque no es solo voluntad. Un compilador puede permitirse conjeturar la intención del programador cuando el espacio de programas válidos es pequeño y la información de tipos es completa; en un lenguaje con inferencia total y sin escotillas, la distancia entre lo que el usuario escribió y lo que probablemente quería escribir suele ser de una operación, y por eso la sugerencia acierta. Donde el sistema de tipos es parcial o admite anotaciones que apagan la verificación, la misma estrategia produce sugerencias erráticas que enseñan a desconfiar del compilador. La calidad del diagnóstico, por tanto, no es una capa de barniz sobre un lenguaje cualquiera: es un dividendo del rigor que se le exigió antes.

error[E0308]: mismatched types
  --> src/main.rs:23:26
   |
23 |     let total: usize = usuarios.len() + nombre;
   |                        --------------   ^^^^^^ expected `usize`, found `String`
   |                        |
   |                        expected because this is `usize`
   |
help: consider using the length of the string instead
   |
23 |     let total: usize = usuarios.len() + nombre.len();
   |                                                ++++++

El compilador como framework

La segunda herencia es más difusa y exige precisión al enunciarla. Elm compila a JavaScript con un runtime deliberadamente pequeño, y como el lenguaje no tiene reflexión ni carga dinámica de código, el compilador puede eliminar de forma agresiva todo lo que no se usa, incluidas funciones concretas dentro de un módulo importado. La consecuencia es que el tamaño del resultado depende de lo que el programa hace y no de lo que la biblioteca ofrece. Svelte defendió públicamente una tesis emparentada: que muchas de las tareas que los frameworks resuelven en tiempo de ejecución, comparando árboles y observando dependencias, se pueden resolver en tiempo de compilación analizando el código fuente, y que el framework ideal es el que desaparece del paquete final. Sería un error afirmar sin pruebas que Svelte descienda de Elm, porque su antecedente inmediato es otro y su autor lo ha explicado varias veces; lo que sí puede afirmarse es que ambos son instancias de la misma tesis y que Elm la encarnaba antes.

// Lo que el programador escribe en un componente compilado
let cuenta = 0
function incrementar() {
  cuenta += 1
}

// Lo que el compilador emite: una invalidacion puntual,
// sin arbol virtual y sin comparacion en tiempo de ejecucion
function incrementar() {
  $$invalidate(0, (cuenta += 1))
}

Los signals: la herejía que también es herencia

La tercera herencia parece una refutación y por eso resulta instructiva. Un signal es una celda de estado que registra quién la lee, de modo que al cambiar puede avisar exactamente a los cálculos y a los fragmentos de interfaz que dependen de ella. La familia es antigua, viene de las bibliotecas de observables de hace quince años y hoy está en Solid, en Vue, en Angular, en Preact y en la versión reciente de Svelte. Su premisa es lo contrario de la de Elm: en vez de un árbol único de estado que se recorre entero en cada cambio, muchas celdas pequeñas, cada una con su grafo de dependencias, y una propagación cuyo coste depende del tamaño del cambio y no del tamaño de la aplicación. Donde Elm dice reconstruye todo y deja que el sistema descubra la diferencia, el signal dice sé exactamente quién te lee y avísale a él.

// El nucleo del mecanismo cabe en veinte lineas
let lectorActual = null

function signal(valorInicial) {
  let valor = valorInicial
  const lectores = new Set()
  return {
    get() {
      if (lectorActual) lectores.add(lectorActual)
      return valor
    },
    set(nuevo) {
      valor = nuevo
      for (const efecto of [...lectores]) efecto()
    },
  }
}

function efecto(fn) {
  const correr = () => {
    lectorActual = correr
    fn()
    lectorActual = null
  }
  correr()
}

Ese fragmento condensa la diferencia filosófica entera. La dependencia no se declara: se descubre observando quién lee durante la ejecución, lo cual exige un estado global temporal y una fase de recolección que el programador no ve. Es un mecanismo brillante y también profundamente implícito, justo la clase de magia que Elm había desterrado por principio. Quien haya depurado un ciclo de actualización inesperado en un sistema reactivo de grano fino reconocerá el precio: cuando la topología del grafo depende de qué ramas se ejecutaron esta vez, razonar sobre ella deja de ser un ejercicio de lectura.

flowchart TB
E[Elm: un estado y reconstruccion total] --> P[Vista como funcion pura del estado]
S[Signals: celdas con grafo de dependencias] --> P
E --> A[Reproduccion e historial gratis]
E --> B[Coste proporcional al arbol]
S --> C[Coste proporcional al cambio]
S --> D[Sin punto unico de auditoria]
P --> F[Herencia comun: nadie muta la interfaz a mano]
style E fill:#a6e3a1,color:#11111b
style S fill:#89b4fa,color:#11111b
style F fill:#cba6f7,color:#11111b

Y sin embargo la herencia está intacta en lo esencial. En un sistema de signals nadie escribe instrucciones para modificar la pantalla: se declara cómo se deriva lo visible de lo almacenado y el sistema se encarga de mantener la correspondencia. Los valores derivados son funciones puras de otros valores. La invalidación manual, que era la fuente principal de errores en la programación de interfaces, ha desaparecido igual que desapareció en Elm, solo que por otro mecanismo. Lo que se cede a cambio es la propiedad que hacía posible el viaje en el tiempo: sin un valor único que contenga todo, no hay nada que guardar, comparar ni reproducir, y la depuración vuelve a ser local. Lo interesante del momento presente es que las arquitecturas más maduras están combinando ambas cosas, con un estado inmutable y único en la cima para poder auditarlo y observación de grano fino por debajo para que la propagación sea barata, que es exactamente lo que hizo The Composable Architecture al adoptar observación en su capa de vista.