Cambio a Elixir
El atractivo de Elixir como un lenguaje funcional al estilo Ruby que se ejecuta sobre la máquina virtual Erlang BEAM es alabado por su tolerancia a fallos, sus procesos ligeros y sus primitivas de concurrencia integradas (OTP), que simplifican el trabajo en segundo plano, los sistemas distribuidos y las aplicaciones web en tiempo real mediante herramientas como Phoenix LiveView. Los comentaristas contrastan esto con ecosistemas como C#, Node.js y Go, debatiendo si la comunidad más pequeña de Elixir, su modelo de despliegue y sus herramientas compensan frente a stacks y frameworks más convencionales como Entity Framework o Hot Chocolate. Un tema recurrente es la tensión entre el tipado dinámico de Elixir y el deseo de garantías estáticas más fuertes, y muchos acogen con satisfacción el sistema de tipos en desarrollo mientras siguen valorando el pattern matching, la inmutabilidad y las fortalezas operativas de BEAM.
Fortalezas principales de Elixir (BEAM/OTP)
- Muchos ven el valor real no en la sintaxis sino en los procesos BEAM, OTP, los árboles de supervisión y el paso de mensajes.
- Se describe como “como k8s sin las partes complicadas” por su fiabilidad, distribución y tolerancia a fallos.
- Los trabajos en segundo plano, los procesos de larga duración y las cargas de trabajo heterogéneas en el mismo clúster se citan como “superpoderes”, especialmente para equipos pequeños.
Concurrencia y trabajo en segundo plano
- Los procesos baratos de Elixir hacen seguro mantener abiertas las solicitudes HTTP durante más tiempo, hacer IO bloqueante o repartir llamadas HTTP sin sistemas de trabajos separados.
- Algunos prefieren una separación estricta entre la web y el cómputo en segundo plano con colas y monitorización externa; otros argumentan que Elixir permite obtener reintentos robustos, back-pressure y supervisión con mucha menos infraestructura.
- Librerías como Oban, Broadway, Flow y Task se destacan por ofrecer múltiples niveles de abstracción para trabajo concurrente.
LiveView y LiveBook
- Se elogia LiveView por hacer fáciles las UIs reactivas y las interfaces “ligeramente JS”, reutilizando validación y estado del backend.
- Algunos lo consideran sencillo una vez que entiendes el modelo mental (websockets + diffs + procesos con estado).
- Otros encuentran que las UIs no triviales pueden “luchar” con el framework, se preocupan por la dependencia de sockets persistentes y lo consideran aún en maduración para apuestas de startups.
Tipado dinámico vs estático
- El hilo está dominado por debates sobre tipos.
- Quienes apoyan los tipos estáticos echan de menos garantías en tiempo de compilación, seguridad al refactorizar, mejor ayuda del IDE y formas de datos más claras; algunos dicen que la falta de tipos acabó haciendo que Elixir resultara desagradable en bases de código grandes.
- Quienes defienden el modelo actual de Elixir señalan el pattern matching, la inmutabilidad, specs + Dialyzer y la inspección en tiempo de ejecución como suficientes para muchos dominios.
- Varios mensajes señalan que un sistema de tipos gradual para Elixir está en desarrollo activo; Gleam se menciona a menudo como una alternativa tipada sobre BEAM.
Ecosistema, herramientas y adopción
- Algunos sostienen que los ecosistemas de Elixir/Erlang están “bien establecidos” y son potentes; otros encuentran que las herramientas (soporte de IDE, documentación de Phoenix/Ecto) son toscas en comparación con ecosistemas principales.
- El soporte para Windows y la integración con k8s u otros runtimes se reportan como puntos problemáticos para algunos.
- El debate sobre “no hay startups exitosas” se contrarresta con ejemplos de productos conocidos y grandes empresas que usan Elixir/BEAM, aunque a veces solo para partes de su stack.
Contratación y dinámica profesional
- Las empresas suelen contratar a ingenieros sólidos sin experiencia previa en Elixir y formarlos, debido a un pequeño grupo de personas con experiencia y al gran interés.
- Otros dicen que los empleos suelen exigir experiencia previa con Elixir, lo que hace difícil entrar sin proyectos paralelos sustanciales.