O que é o Elixir de verdade: um guia de campo para devs de JavaScript, Java e .NET

Um guia de campo para devs senior de JavaScript, Java e .NET, e para os CTOs que precisam aprovar a aposta.

TL;DR

Elixir é uma linguagem funcional, de tipagem dinâmica, com uma sintaxe amigável e com jeitinho de Ruby, que compila para rodar sobre o BEAM, a máquina virtual construída nos anos 80 para o Erlang, pensada para centrais telefônicas que não podiam parar. Você escreve um código que parece moderno e acessível; por baixo, você herda três décadas de engenharia testada em concorrência, tolerância a falhas e sistemas distribuídos.

Essa é a troca em uma frase só: ergonomia moderna para o desenvolvedor sobre uma infraestrutura de concorrência testada em batalha. O resto é detalhe.

Você já colocou sistemas em produção. Já depurou condições de corrida às 2 da manhã, já escalou um serviço até o banco de dados implorar por clemência, e já reescreveu o mesmo código de "disparar cem requisições e não cair" em três linguagens diferentes. Você não precisa de mais um tour de "hello world".

Aqui está o que o Elixir realmente é, por que uma linguagem que roda sobre uma máquina virtual de 39 anos continua aparecendo em infraestrutura séria, e como pensar nisso se você passou a carreira no mundo de JavaScript, Java ou .NET.

Estamos publicando isso antes da nossa entrevista com José Valim, o criador do Elixir. Pense nisso como o aquecimento: o contexto que você vai querer ter na cabeça antes de ouvir direto da fonte.

O problema que o Elixir realmente resolve

A maioria das linguagens que você conhece foi desenhada em um mundo onde um programa significava uma única thread de execução, e a concorrência foi encaixada depois, como um remendo.

• O JavaScript apostou tudo em um event loop de uma única thread. Ótimo para I/O, mas no momento em que você precisa de paralelismo real, acaba recorrendo a worker threads, processos filhos ou uma fila, e o estado compartilhado vira um problema rápido.
• Java e .NET te dão threads reais e thread pools excelentes, mas threads são pesadas, e memória mutável compartilhada protegida por locks é uma das fontes mais confiáveis de bugs em produção já inventadas. Deadlocks, condições de corrida e "isso só acontece sob carga" são o gênero.

O Elixir assume uma postura diferente: milhares ou milhões de processos pequenos e isolados, cada um com sua própria memória privada, que nunca compartilham estado e se comunicam só por troca de mensagens. Esses não são threads do sistema operacional. Eles são agendados pelo BEAM e custam quase nada para criar. Se um cai, cai sozinho; ele não pode corromper a memória dos vizinhos, porque de cara não tem acesso a essa memória.

Se você já admirou a ideia das goroutines do Go ou o modelo de atores do Akka, essa é a mesma linhagem, só que no BEAM não é uma biblioteca que se escolhe adotar: é o alicerce sobre o qual toda a linguagem foi construída.

O retorno prático para um engenheiro senior: uma classe enorme de bugs de concorrência que você aprendeu a temer simplesmente não tem onde acontecer. Não há estado mutável compartilhado para proteger, então não há locks para esquecer.

"Let it crash" não é imprudência, é uma estratégia

Essa é a parte que costuma quebrar a cabeça de quem vem de culturas de programação defensiva.

Em um serviço típico de Java, .NET ou Node, você embrulha código arriscado em try/catch e tenta prever cada falha possível, porque uma exceção não tratada pode derrubar o processo inteiro. O instinto é: nunca deixar nada falhar.

O mundo do BEAM inverte isso. Processos são baratos e isolados, e são organizados em árvores de supervisão: um processo cujo único trabalho é vigiar outros processos e reiniciá-los em um estado conhecido e saudável quando morrem. Então, em vez de programar na defensiva contra cada falha possível, você deixa um processo com mau comportamento cair, limpo e rápido, e deixa o supervisor dele levantar um novo.

O resultado são sistemas que se autocuram. Uma falha transitória (uma mensagem ruim, uma chamada externa instável) mata um processo pequeno e o reinicia em microssegundos, enquanto os outros 200.000 processos nem percebem. É a mesma filosofia que manteve as centrais telefônicas em "nove noves" de disponibilidade (cerca de 31 milissegundos de indisponibilidade por ano). Você não está comprando uma sintaxe. Você está comprando um modelo operacional.

Como isso se parece na prática

Você não precisa ler Elixir fluentemente para sentir o clima. Três coisas chamam a atenção de quem chega:

O operador pipe

A transformação de dados se lê de cima para baixo, como um pipeline de Unix:

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

Se você já escreveu correntes de array.map().filter().reduce() em JS, isso vai parecer instantaneamente familiar, só que se generaliza para qualquer função, não só para métodos de um objeto.

Pattern matching em vez de ramificações

O sinal = não é uma atribuição, é uma afirmação de que duas formas coincidem, e você vai desestruturando conforme avança. Isso substitui uma quantidade impressionante de if/switch e verificações de null.

Imutabilidade em tudo

Os dados não mudam no lugar; você os transforma em dados novos. Se você vem do JavaScript com pegada funcional (pense nos reducers do Redux, const, spread operators), isso é uma diferença de grau, não de tipo. O Elixir simplesmente torna isso o padrão em vez de uma disciplina que você precisa se impor a cada code review.

"O ecossistema realmente existe?", a pergunta real do CTO

Uma linguagem bonita sem bibliotecas é um hobby. Este é o panorama honesto:

• Phoenix é o framework web, e é maduro, rápido e produtivo. Se você vem de Rails, Django ou Spring, vai reconhecer a estrutura na hora: rotas, controllers, views, tudo incluído.
• Ecto é a camada de banco de dados. Não é bem um ORM no estilo ActiveRecord: é mais explícito e mais componível, algo que engenheiros senior tendem a preferir depois que superam o "cadê a mágica?" inicial.
• Phoenix LiveView é o item genuinamente novo. Ele deixa você construir interfaces ricas, em tempo real e interativas, com estado renderizado no servidor e quase nenhum JavaScript escrito à mão. Para muitos produtos com muito CRUD ou estilo dashboard, ele colapsa a separação entre front-end e back-end em um único codebase. Times que adotam costumam descrever isso como sua vantagem desleal em velocidade de entrega.

O ecossistema é tão vasto quanto o npm ou o Maven Central? Não, e quem disser o contrário está vendendo alguma coisa. Há menos pacotes, menos respostas no Stack Overflow e um pool de contratação menor. Mas as bibliotecas que existem tendem a ter alta qualidade, e as lacunas estão na amplitude (algum SDK de nicho de terceiros pode não ter cliente oficial), não no essencial. A história central (web, APIs, tempo real, jobs em background, clustering) está bem coberta.

Onde o Elixir realmente brilha

É preciso ser honesto sobre o encaixe. O Elixir não é a resposta universal, e fingir o contrário é um desserviço. Ele se justifica quando seu problema se parece com um destes:

• Conexões concorrentes massivas: chat, mensageria, presença, multiplayer, colaboração ao vivo, frotas de IoT. O exemplo clássico é o WhatsApp lidando com milhões de conexões por servidor (em Erlang, a outra linguagem do BEAM). Esse é o campo de casa.
• Sistemas em tempo real ou quase real: dashboards ao vivo, cotações financeiras, notificações, qualquer coisa em que o "push" importe mais que o "poll".
• Backends de alta disponibilidade em que o downtime é genuinamente caro e, caso contrário, você estaria montando resiliência à base de Kubernetes, retries, circuit breakers e fé.
• Pipelines de dados e orquestração: coordenar milhares de jobs concorrentes com backpressure (a história do GenStage/Broadway) é algo para o qual o runtime foi construído.

Onde ele não é a escolha óbvia: processamento pesado de CPU (o BEAM não é otimizado para computação bruta em uma única thread, embora haja trabalho interessante acontecendo com compilação nativa e ML), scripts pequenos em que o runtime é demais, ou um time e um codebase em que toda a gravidade da organização está em outro stack e o problema não exige concorrência.

A verdade sobre a curva de aprendizado

• Para um desenvolvedor de JavaScript: a sintaxe é fácil e o tooling é agradável. O obstáculo real é o modelo mental. Você vai passar as primeiras semanas desaprendendo loops (vai usar recursão e funções de Enum), desaprendendo variáveis mutáveis e reprogramando seu instinto de recorrer a estado compartilhado. A boa notícia: boa parte do JS moderno (dados imutáveis, .map/.filter/.reduce, padrões async) já vinha te preparando para isso sem que você percebesse. As ideias funcionais entram mais rápido do que você esperaria.
• Para desenvolvedores de Java/.NET: você já respeita engenharia sólida e já sentiu na pele a dor de threads e locks, então a proposta de valor faz sentido de imediato. O ajuste é sair da tipagem estática e das hierarquias de classes para tipagem dinâmica e dados-mais-funções. (Se tipagem estática é inegociável para você, vale saber que o Elixir está ativamente ganhando um sistema de tipos gradual, um esforço real e em andamento, não é papo furado.)

O padrão nos dois casos: a linguagem se aprende em alguns dias; o paradigma, em algumas semanas; e a maioria de quem atravessa isso relata que mudou de forma permanente como pensa todo o próprio código, incluindo o que escreve de volta na linguagem do dia a dia.

Então, vale a pena apostar?

Se você é CTO ou staff engineer, a pergunta certa não é "o Elixir é bom?" (é). É "meu problema combina com as forças dele, e eu consigo sustentar o time?". Recorra a ele quando concorrência, comportamento em tempo real ou uptime forem centrais para o produto, e não incidentais. É aí que ele compensa o pool de contratação menor, muitas vezes. Seja mais cauteloso quando estiver adotando só pela novidade, ou quando seu problema for claramente de CPU ou for resolvido trivialmente pelo stack que você já usa. Um detalhe subestimado: times de Elixir costumam ser pequenos, e o tipo de desenvolvedor que ele atrai tende a ser curioso e senior, o que já é um filtro de contratação em si.

Se você é um desenvolvedor individual, a aposta é mais barata e o ganho é real. Mesmo que você nunca coloque Elixir em produção, aprendê-lo vai te tornar um engenheiro mensuravelmente melhor em qualquer linguagem que pague suas contas, porque isso força um entendimento claro de imutabilidade, concorrência por troca de mensagens e design para a falha. Poucas linguagens ensinam isso de forma tão direta.

O que vem a seguir

Este artigo é a rampa de entrada. As perguntas mais profundas (por que criar uma linguagem nova em 2011 em vez de arrumar o que já existia? por que a VM do Erlang e não a JVM? por que não escrever Erlang direto? o Elixir resolve mesmo todo problema de concorrência, ou isso é só marketing?) são exatamente o que perguntamos para José Valim em pessoa.

Também entramos nas partes que você não lê em um site de documentação: como é, na prática, desenhar uma linguagem de programação, como ele pensa o top-down versus o bottom-up ao encarar problemas genuinamente difíceis, onde a IA entra na história do Elixir, e como é um dia de trabalho normal para alguém que criou uma linguagem da qual milhares de times hoje dependem.

A entrevista completa chega em breve. Se isso despertou sua curiosidade, você vai querer ouvir o resto de quem criou tudo isso.