09.10.2026 · Signal Titans Editorial

Joe Armstrong construyó Erlang sobre una regla extraña: déjalo fallar. Sus famosos “nueve nueves” necesitan una nota al pie.

Joe Armstrong sonriendo con gorra en una conferencia, junto a un panel luminoso con un diagrama de árbol de supervisión que muestra un proceso caído y su nombre.

Casi todos los consejos de programación sobre errores se resumen en una palabra: prevenir. Comprobar la entrada, proteger el puntero, envolver la llamada. El consejo de Joe Armstrong, escrito en su tesis doctoral de 2003, suena al revés: "Si no puedes hacer lo que quieres hacer, muere. Deja que falle. No programes a la defensiva."

No hablaba de código de aficionado. Hablaba de cómo Ericsson construía centrales telefónicas, máquinas que debían seguir funcionando durante años. La frase "let it crash" se convirtió en el lema más conocido de Erlang y también en uno de los más malentendidos. Lo mismo ocurre con la cifra famosa que lo acompaña: nueve nueves de fiabilidad.

Una máquina que nunca puede detenerse

Armstrong entró en el Laboratorio de Informática de Ericsson en Estocolmo en 1985. Su jefe, Bjarne Däcker, le dio un encargo que Armstrong citó más tarde en su historia del lenguaje: "resolver el problema de software de Ericsson". El objetivo del laboratorio, según lo describió, era "ofrecer una mejor forma de programar aplicaciones de telefonía".

La telefonía era un objetivo difícil. Una sola central debe manejar "decenas o cientos de miles de transacciones simultáneas", escribió Armstrong. Su software tenía que modificarse mientras funcionaba, "sin pérdida de servicio". Y una regla venía directa de las centrales AXE de Ericsson: el fallo de un proceso "solo debería influir en la transacción inmediata implicada". No se podía permitir que una llamada rota arrastrara consigo a todas las demás.

Cuando Armstrong y su colega Robert Virding preguntaban a investigadores en congresos qué pasaba si uno de sus nodos fallaba, las respuestas no eran alentadoras. Las más habituales, recordó Armstrong, eran "el sistema no funcionará" o "nuestro modelo asume que no hay fallos".

De un lento modelo en Smalltalk a un lenguaje nuevo

Armstrong modeló primero la telefonía en Smalltalk, pero "Smalltalk era muy lento". Cuando le enseñó su notación a un colega, Roger Skagervall, la respuesta fue breve: "eso es un programa en Prolog". Erlang empezó, en palabras de Armstrong, como "añadir concurrencia a Prolog", ejecutándose como un intérprete escrito en el propio Prolog. El desarrollo comenzó en 1986.

Pronto dejó de ser un proyecto de una sola persona. Virding escribió una segunda implementación. Mike Williams encontró los primeros usuarios internos en 1987 y más tarde escribió el emulador en C de la máquina virtual de Erlang. Williams aportó también la idea de los enlaces entre procesos, que Armstrong atribuye al "mecanismo de liberación de los antiguos teléfonos analógicos". Ese detalle importa: el núcleo del manejo de errores de Erlang se tomó prestado del hardware que debía sustituir.

Qué significa realmente "let it crash"

Leído por sí solo, "let it crash" suena a permiso para ignorar los errores. La tesis dice algo más concreto. Su lista completa de lemas empieza con "Que otro proceso se encargue de la recuperación de errores". El modelo, explicó Armstrong, son dos ordenadores que se vigilan mutuamente: "Usamos exactamente el mismo método en Erlang, solo que en lugar de ordenadores usamos pares de procesos".

En la práctica, un proceso trabajador hace el trabajo y un proceso supervisor distinto lo vigila. Los procesos de Erlang no comparten memoria, así que un trabajador que falla no puede corromper a sus vecinos. Cuando muere, el enlace avisa al supervisor, que lo vuelve a arrancar. El supervisor puede incluso estar en otra máquina porque, como dijo Armstrong, "no se puede construir un sistema tolerante a fallos si solo se tiene un ordenador".

La tesis también traza una línea que la mayoría de los resúmenes omite. Si el programador "sabe qué hacer para corregir la condición que causó la excepción, entonces eso no es un error". Un archivo que falta puede capturarse y resolverse allí donde ocurre. El fallo se reserva para los casos en que "el programador no sabe qué hacer", los estados inesperados en los que el código defensivo suele adivinar y empeorar las cosas. Armstrong fue honesto también sobre los límites: el aislamiento entre procesos, escribió, "no es perfecto", y un proceso aún puede montar lo que equivale a un ataque de denegación de servicio contra otro.

El AXD301 y los nueve nueves

La idea tuvo su gran prueba después de que el proyecto AXE-N de Ericsson se derrumbara en diciembre de 1995, un hecho que Armstrong llamó "el acontecimiento más importante de la historia de Erlang". Se eligió Erlang para el nuevo conmutador ATM AXD301, construido por más de 60 programadores de Erlang y organizado en torno a los "árboles de supervisión" de OTP. Una instantánea de finales de 2001 contaba alrededor de 1,1 millones de líneas de código Erlang.

El AXD301 es el origen de la leyenda. Armstrong escribió que "logró una fiabilidad de NUEVE nueves", lo que equivale a unos 31 milisegundos de inactividad al año. La cifra se ha repetido desde entonces como si fuera una propiedad del propio Erlang.

Las fuentes cuentan una historia más acotada. La propia tesis de Armstrong admite que la única evidencia a largo plazo era "una presentación de PowerPoint" en la que un cliente importante informaba de un sistema de 11 nodos al 99,9999999 %, "aunque no se documentó cómo se habían obtenido esas cifras". Mats Cronqvist, arquitecto de sistemas del AXD301, explicó después que British Telecom "afirmaba una disponibilidad de servicio de nueve nueves integrada sobre unos 5 años-nodo". También señaló que había "mucho más C que Erlang en el sistema" y que Armstrong "no formaba parte del equipo del AXD 301". Calificó la afirmación de "bastante falsa", pero añadió que, comparado con sistemas similares, el conmutador "era asombrosamente fiable". Ulf Wiger, que dirigió el diseño del AXD301, confirmó que la cifra era un dato real de un cliente y dijo que otros despliegues eran "sistemáticamente mejores que el 99,999 %".

Así que la versión documentada es menos mágica, pero sigue siendo impresionante: la disponibilidad que informó un cliente para una red, no una ley medida del lenguaje.

Prohibido y luego liberado

El éxito no protegió a Erlang dentro de Ericsson. En febrero de 1998, Ericsson Radio Systems lo prohibió para productos nuevos. Un documento interno de política dio la razón: un "lenguaje propietario" implicaba un esfuerzo continuo para mantener su soporte y sus herramientas. Däcker señaló después la ironía de que esa "insistencia en lo 'propietario'" hizo posible liberar Erlang como código abierto, lo que Ericsson hizo en diciembre de 1998. Armstrong y la mayor parte del equipo central se marcharon entonces a fundar una startup, Bluetail. Su veredicto sobre la prohibición: Ericsson "hizo lo correcto (usar la tecnología adecuada para el trabajo) por las razones equivocadas".

El código abierto dio a Erlang una segunda vida. En 2012, los ingenieros de WhatsApp escribieron en su blog que Erlang era una pieza clave de su infraestructura y mostraron un único servidor con más de 2 millones de conexiones TCP. Armstrong murió en abril de 2019; la comunidad de Erlang lo recordó como el padre del lenguaje.

La idea que sobrevivió a la central

Hoy pocos equipos construyen centrales telefónicas, pero muchos construyen sistemas que reinician servicios caídos, aíslan cargas de trabajo y aceptan que siempre habrá algo roto en alguna parte. La aportación de Armstrong fue convertir esa suposición en el punto de partida y no en una ocurrencia posterior.

La pregunta útil que deja su trabajo no es "¿cómo evito que esto falle?". Es esta: cuando esta pieza falle, ¿quién se entera y quién la devuelve a la vida?