Qué es realmente Elixir: una guía de campo para devs de JavaScript, Java y .NET

Una guía de campo para devs senior de JavaScript, Java y .NET, y para los CTOs que tienen que aprobar la apuesta.

TL;DR

Elixir es un lenguaje funcional, de tipado dinámico, con una sintaxis amigable y con sabor a Ruby que compila para correr sobre el BEAM, la máquina virtual construida en los años 80 para Erlang, pensada para centrales telefónicas que no podían caerse. Escribes código que se ve moderno y accesible; por debajo, heredas tres décadas de ingeniería probada en concurrencia, tolerancia a fallos y sistemas distribuidos.

Ese es el trato en una sola frase: ergonomía moderna para el desarrollador sobre una infraestructura de concurrencia curtida en batalla. Todo lo demás es detalle.

Ya lanzaste sistemas a producción. Depuraste condiciones de carrera a las 2 de la mañana, escalaste un servicio hasta que la base de datos no dio más, y reescribiste el mismo código de "disparar cien requests y no caerte" en tres lenguajes distintos. No necesitas otro tour de "hello world".

Acá va lo que Elixir realmente es, por qué un lenguaje que corre sobre una máquina virtual de 39 años sigue apareciendo en infraestructura seria, y cómo pensarlo si pasaste tu carrera en el mundo de JavaScript, Java o .NET.

Publicamos esto antes de nuestra entrevista con José Valim, el creador de Elixir. Piénsalo como el calentamiento: el contexto que vas a querer tener en la cabeza antes de escucharlo directo de la fuente.

El problema que Elixir realmente resuelve

La mayoría de los lenguajes que conoces se diseñaron en un mundo donde un programa significaba un solo hilo de ejecución, y la concurrencia se agregó después, como un parche.

• JavaScript apostó todo a un event loop de un solo hilo. Genial para I/O, pero en el momento en que necesitas paralelismo real, terminas recurriendo a worker threads, procesos hijos o una cola, y el estado compartido se vuelve incómodo rápido.
• Java y .NET te dan threads reales y thread pools excelentes, pero los threads son pesados, y la memoria mutable compartida protegida por locks es una de las fuentes más confiables de bugs en producción jamás inventadas. Deadlocks, condiciones de carrera y "esto solo pasa bajo carga" son el género.

Elixir toma una postura distinta: miles o millones de procesos pequeños y aislados, cada uno con su propia memoria privada, que nunca comparten estado y se comunican solo pasándose mensajes. Estos no son threads del sistema operativo. Los planifica el BEAM y cuestan casi nada de levantar. Si uno se cae, se cae solo; no puede corromper la memoria de sus vecinos, porque de entrada no tiene acceso a esa memoria.

Si alguna vez admiraste la idea de las goroutines de Go o el modelo de actores de Akka, esta es la misma línea de sangre, salvo que en el BEAM no es una librería que se elige adoptar: es el piso sobre el que está construido todo el lenguaje.

La recompensa práctica para un ingeniero senior: una clase enorme de bugs de concurrencia que aprendiste a temer simplemente no tiene dónde ocurrir. No hay estado mutable compartido que proteger, así que no hay locks que olvidar.

"Let it crash" no es imprudencia, es una estrategia

Esta es la parte que suele romperle la cabeza a quien viene de culturas de programación defensiva.

En un servicio típico de Java, .NET o Node, envuelves el código riesgoso en try/catch e intentas anticipar cada falla posible, porque una excepción sin manejar puede tirar abajo todo el proceso. El instinto es: nunca dejar que nada falle.

El mundo del BEAM invierte esto. Los procesos son baratos y aislados, y se organizan en árboles de supervisión: un proceso cuyo único trabajo es vigilar a otros procesos y reiniciarlos en un estado conocido y sano cuando mueren. Entonces, en lugar de programar a la defensiva contra cada falla posible, dejas que un proceso que se porta mal se caiga, limpio y rápido, y dejas que su supervisor levante uno nuevo.

El resultado son sistemas que se autocuran. Una falla transitoria (un mensaje corrupto, una llamada a un servicio externo que falló) mata a un proceso pequeño y lo reinicia en microsegundos, mientras los otros 200.000 procesos ni se enteran. Es la misma filosofía que mantuvo a las centrales telefónicas en "nueve nueves" de disponibilidad (unos 31 milisegundos de caída al año). No estás comprando una sintaxis. Estás comprando un modelo operativo.

Cómo se ve en la práctica

No necesitas leer Elixir con fluidez para captar la idea. Hay tres cosas que llaman la atención de quien recién llega:

El operador pipe

La transformación de datos se lee de arriba hacia abajo, como un pipeline de Unix:

• "hello world"
• |> String.split()
• |> Enum.map(&String.capitalize/1)
• |> Enum.join(" ")
• # => "Hello World"

Si alguna vez escribiste cadenas de array.map().filter().reduce() en JS, esto te va a resultar instantáneamente familiar, salvo que se generaliza a cualquier función, no solo a métodos de un objeto.

Pattern matching en lugar de ramificaciones

El signo = no es una asignación, es una aserción de que dos formas coinciden, y vas desestructurando a medida que avanzas. Esto reemplaza una cantidad sorprendente de if/switch y de chequeos de null.

Inmutabilidad en todos lados

Los datos no cambian en su lugar; los transformas en datos nuevos. Si vienes del JavaScript con onda funcional (piensa en los reducers de Redux, const, spread operators), esto es una diferencia de grado, no de tipo. Elixir simplemente lo vuelve el default en lugar de una disciplina que tienes que imponerte a mano en cada code review.

"¿El ecosistema realmente existe?", la pregunta real del CTO

Un lenguaje hermoso sin librerías es un hobby. Este es el panorama honesto:

• Phoenix es el framework web, y es maduro, rápido y productivo. Si vienes de Rails, Django o Spring, vas a reconocer la forma de inmediato: routing, controllers, views, todo el paquete.
• Ecto es la capa de base de datos. No es exactamente un ORM al estilo ActiveRecord: es más explícito y más componible, algo que los ingenieros senior tienden a preferir una vez que superan el "¿y dónde está la magia?" inicial.
• Phoenix LiveView es la pieza genuinamente novedosa. Te deja construir interfaces ricas, en tiempo real e interactivas, con estado renderizado en el servidor y casi nada de JavaScript escrito a mano. Para muchos productos tipo CRUD o dashboard, colapsa la separación entre frontend y backend en un solo codebase. Los equipos que lo adoptan suelen describirlo como su ventaja injusta en velocidad de entrega.

¿El ecosistema es tan vasto como npm o Maven Central? No, y quien te diga lo contrario te está vendiendo algo. Hay menos paquetes, menos respuestas en Stack Overflow y un pool de contratación más chico. Pero las librerías que existen suelen ser de alta calidad, y los huecos están en amplitud (algún SDK de nicho de un tercero puede no tener cliente oficial), no en lo fundamental. La historia central (web, APIs, tiempo real, jobs en background, clustering) está bien cubierta.

Dónde Elixir realmente brilla

Hay que ser honesto sobre el fit. Elixir no es la respuesta universal, y aparentar lo contrario le hace un flaco favor. Se gana su lugar cuando tu problema se parece a alguno de estos:

• Conexiones concurrentes masivas: chat, mensajería, presencia, multiplayer, colaboración en vivo, flotas de IoT. El caso de jactancia clásico es WhatsApp manejando millones de conexiones por servidor (sobre Erlang, el otro lenguaje del BEAM). Esta es la cancha propia.
• Sistemas en tiempo real o casi real: dashboards en vivo, cotizaciones financieras, notificaciones, cualquier cosa donde el "push" importe más que el "poll".
• Backends de alta disponibilidad donde el downtime es genuinamente costoso y de otro modo estarías armando resiliencia a fuerza de Kubernetes, reintentos, circuit breakers y fe.
• Pipelines de datos y orquestación: coordinar miles de jobs concurrentes con backpressure (la historia de GenStage/Broadway) es algo para lo que el runtime está construido.

Donde no es la elección obvia: cómputo intensivo de CPU (el BEAM no está optimizado para cómputo crudo en un solo hilo, aunque hay trabajo interesante pasando con compilación nativa y ML), scripts chicos donde el runtime es demasiado, o un equipo y un codebase donde toda la gravedad de la organización está en otro stack y el problema no exige concurrencia.

La verdad sobre la curva de aprendizaje

• Para un desarrollador de JavaScript: la sintaxis es fácil y el tooling es agradable. El obstáculo real es el modelo mental. Vas a pasar las primeras semanas desaprendiendo loops (vas a usar recursión y funciones de Enum), desaprendiendo variables mutables y reprogramando tu instinto de recurrir al estado compartido. La buena noticia: buena parte del JS moderno (datos inmutables, .map/.filter/.reduce, patrones async) te viene preparando para esto sin que te dieras cuenta. Las ideas funcionales calan más rápido de lo que esperarías.
• Para desarrolladores de Java/.NET: ya respetas la ingeniería sólida y ya sentiste el dolor de los threads y los locks, así que la propuesta de valor se entiende de inmediato. El ajuste es pasar de tipado estático y jerarquías de clases a tipado dinámico y datos-más-funciones. (Si el tipado estático es innegociable para ti, vale la pena saber que Elixir está ganando activamente un sistema de tipos gradual, un esfuerzo real y en curso, no vaporware.)

El patrón en ambos casos: el lenguaje se aprende en unos días; el paradigma, en unas semanas; y la mayoría de quienes lo atraviesan reportan que cambió de manera permanente cómo piensan todo su código, incluido el que escriben de vuelta en su lenguaje del día a día.

Entonces, ¿vale la pena apostarle?

Si eres CTO o staff engineer, el enfoque correcto no es "¿Elixir es bueno?" (lo es). Es "¿mi problema calza con sus fortalezas, y puedo sostener al equipo?". Recurre a él cuando la concurrencia, el comportamiento en tiempo real o el uptime sean centrales para el producto, y no incidentales. Ahí es donde compensa el pool de contratación más chico, muchas veces de sobra. Sé más cauteloso cuando lo estés adoptando solo por novedad, o cuando tu problema sea claramente de CPU o esté trivialmente resuelto por el stack que ya tienes. Un detalle subestimado: los equipos de Elixir suelen ser chicos, y el tipo de desarrollador que atrae tiende a ser curioso y senior, lo cual es en sí mismo un filtro de contratación.

Si eres un desarrollador individual, la apuesta es más barata y el upside es real. Incluso si nunca llevas Elixir a producción, aprenderlo te va a hacer un ingeniero mejor de manera medible en el lenguaje que sea que te paga las cuentas, porque te obliga a entender con claridad la inmutabilidad, la concurrencia por paso de mensajes y el diseño para la falla. Pocos lenguajes enseñan eso tan directamente.

Qué sigue

Este artículo es la rampa de entrada. Las preguntas más profundas (¿por qué construir un lenguaje nuevo en 2011 en lugar de arreglar lo que ya existía? ¿por qué la VM de Erlang y no la JVM? ¿por qué no escribir Erlang directamente? ¿Elixir realmente resuelve todo problema de concurrencia, o eso es marketing?) son exactamente las que le hicimos a José Valim en persona.

También entramos en las partes que no se leen en un sitio de docs: cómo es en la práctica diseñar un lenguaje de programación, cómo piensa el top-down versus el bottom-up al enfrentar problemas genuinamente difíciles, dónde entra la IA en la historia de Elixir, y cómo es un día de trabajo normal para alguien que creó un lenguaje del que hoy dependen miles de equipos.

La entrevista completa llega pronto. Si esto te dejó con ganas, vas a querer escuchar el resto de boca de quien lo creó.