Cero errores en runtime: la garantía y su precio

Ningún lenguaje de aplicación de uso general se atreve a poner en su página principal la frase que Elm lleva años exhibiendo: sin excepciones en tiempo de ejecución. No es una promesa de marketing formulada con ambigüedad calculada, sino una afirmación técnica comprobable, y equipos que mantienen bases de código de centenares de miles de líneas la han confirmado durante años con anécdotas que en cualquier otro entorno sonarían inverosímiles, del tipo un único fallo en producción en varios años de desarrollo continuo. Ahora que has visto Maybe y Result desde dentro, estás en condiciones de entender por qué la afirmación se sostiene, algo mucho más interesante que creerla. La garantía no viene de un análisis estático sofisticado ni de una demostración formal impenetrable: viene de un puñado de decisiones austeras, cada una de las cuales cierra una vía de fallo, y que juntas dejan al programa sin sitios por donde reventar. Pero toda garantía se paga, y este cierre de nivel tiene dos obligaciones: mostrar de dónde sale la promesa y, con la misma honestidad, decir qué cuesta y qué no cubre.

De dónde sale la garantía

Ninguna de las piezas basta por sí sola; el resultado nace de que ninguna deja huecos que las otras tengan que tapar. La eliminación de null suprime la desreferencia de valor ausente, que es la primera causa de fallos en producción de la industria. La eliminación de las excepciones suprime el canal de control invisible, y con él la posibilidad de que un fallo escape sin ser tratado. Las funciones parciales de la biblioteca se convierten en totales devolviendo Maybe o Result, de modo que no quedan entradas para las que el comportamiento no esté definido. La exhaustividad obligatoria del case impide dejar sin cubrir cualquiera de esos resultados. La inmutabilidad elimina la mutación concurrente y el aliasing sorpresa. La pureza garantiza que ninguna función haga nada que su tipo no anuncie.

-- La frontera con el exterior: nada entra sin declarar su forma
type alias Chiste =
    { texto : String, votos : Int }


decodChiste : Decode.Decoder Chiste
decodChiste =
    Decode.map2 Chiste
        (Decode.field "texto" Decode.string)
        (Decode.field "votos" Decode.int)


-- Decodificar produce un Result, nunca una excepcion
-- Decode.decodeValue : Decoder a -> Value -> Result Decode.Error a

La cuarta pieza merece un párrafo aparte porque es la que suele decidir el resultado en la práctica. En la mayoría de los proyectos, los fallos de producción no nacen del código propio sino de datos ajenos que no tenían la forma prevista: un campo que el servidor dejó de enviar, un nulo donde había un número, un formato de fecha que cambió. Elm no permite que un valor externo entre en el programa sin pasar por un decodificador que declara exactamente qué forma espera, y el resultado de decodificar es un Result. La sorpresa se convierte así en un valor de fallo que tu código trata igual que cualquier otro, en el mismo instante en que ocurre y en el único punto donde puede ocurrir. Esta frontera, y no la elegancia del núcleo funcional, es la razón por la que la promesa aguanta en aplicaciones que hablan con servicios reales.

La letra pequeña

La honestidad intelectual exige leer la promesa con lupa, y Elm lo hace: la formulación cuidadosa habla de excepciones en tiempo de ejecución en la práctica, no de corrección absoluta. Estas son las grietas conocidas, y conviene tenerlas presentes para no confundir una garantía muy fuerte con una imposible.

-- Grietas reconocidas de la promesa
-- 1. Debug.todo detiene el programa a proposito: es un marcador de trabajo pendiente
siguiente : Estado -> Estado
siguiente estado =
    Debug.todo "pendiente de implementar"


-- 2. La recursion sin caso base no termina; el tipo no dice nada del tiempo
bucle : Int -> Int
bucle n =
    bucle (n + 1)


-- 3. Un Maybe mal resuelto no rompe, pero puede mentir
edad : Int
edad =
    Maybe.withDefault 0 (String.toInt "no es un numero")

Hay más matices. La aritmética no lanza: dividir entre cero produce un valor especial en coma flotante en vez de detener el programa, lo cual evita la excepción pero puede propagar un número sin sentido. La recursión muy profunda puede agotar la pila del entorno anfitrión, que es una limitación de la máquina y no del tipado. La inicialización desde JavaScript puede fallar si el nodo del documento no existe o si los datos iniciales no encajan con lo declarado. Y ningún sistema de tipos impide el error más frecuente de todos: que el programa haga exactamente lo que escribiste y lo que escribiste no fuera lo que el negocio necesitaba.

El precio

Nada de esto es gratis, y una guía honesta debe poner la factura sobre la mesa. El primer coste es la ceremonia. Escribir un case con su rama de ausencia, o encadenar tres andThen para lo que en otro lenguaje sería un acceso encadenado con un signo de interrogación, es más código y más lento de teclear. Buena parte de ese coste desaparece con soltura y con las funciones del nivel anterior, pero no desaparece del todo, y en prototipos desechables se siente como fricción pura.

El segundo coste es la ausencia de escotillas de emergencia. En otros lenguajes con tipos fuertes existe siempre una forma de decirle al compilador confía en mí y seguir adelante. Elm no la tiene: no hay conversión insegura, no hay tipo comodín, no hay forma de llamar a JavaScript directamente desde una función. Cuando el sistema de tipos se equivoca contigo, no hay recurso, y hay que modelar el problema hasta que encaje. Es la misma decisión que produce la garantía, vista desde el otro lado.

El tercer coste es el ecosistema. La imposibilidad de incrustar JavaScript arbitrario en un paquete —una restricción endurecida deliberadamente en la versión 0.19— mantiene la garantía intacta a costa de que integrar una biblioteca externa exija escribir puertos y decodificadores a mano. La comunidad es pequeña, el ritmo de publicación del lenguaje ha sido muy pausado durante años y el gobierno del proyecto está concentrado en muy pocas manos. Y en el plano técnico, la ausencia de clases de tipos impide escribir un map genérico que sirva para cualquier contenedor: hay que repetir la misma función en cada módulo.

flowchart LR
D[Decisiones austeras] --> G[Clase de fallos imposible]
D --> P[Precio inevitable]
G --> B[Confianza al desplegar]
P --> C[Ceremonia y ecosistema pequeno]
B --> J[Juicio del proyecto]
C --> J
style G fill:#a6e3a1,color:#11111b
style P fill:#f9e2af,color:#11111b
style J fill:#cba6f7,color:#11111b

Lo que se exporta de este experimento

Antes de juzgar la transacción conviene fijar el criterio, porque no hay una respuesta universal. Un prototipo que vivirá una semana, un equipo que necesita cientos de bibliotecas del ecosistema de JavaScript o un producto cuyo mayor riesgo es llegar tarde al mercado pagan la ceremonia sin cobrar el beneficio, porque el beneficio se cobra en el mantenimiento y ese código no llegará a mantenerse. Una aplicación de larga vida, con reglas de negocio densas, con un equipo que rota y con un coste alto por cada fallo que llega al usuario, está exactamente en el otro extremo: ahí la garantía se cobra todos los días y la ceremonia se amortiza en el primer refactor grande.

Aunque nunca escribas una aplicación en Elm, sus ideas ya han llegado a tus herramientas. El tipo opcional explícito de Swift y de Kotlin, el Option y el Result de Rust con su exhaustividad obligatoria, la comprobación estricta de nulos de TypeScript y las bibliotecas de resultados que han proliferado en todos los lenguajes descienden de la misma intuición. Elm ha funcionado como un experimento controlado que llevó la idea hasta el final sin concesiones para ver qué pasaba, y lo que pasó fue que la clase de fallos desapareció. Los lenguajes mayoritarios adoptan después una versión atenuada, compatible con su legado, que captura buena parte del beneficio a cambio de renunciar a la garantía absoluta.