Mudando para Elixir
O apelo do Elixir como uma linguagem funcional parecida com Ruby, rodando na VM Erlang BEAM, é elogiado por sua tolerância a falhas, processos leves e primitivas de concorrência integradas (OTP), que simplificam trabalho em segundo plano, sistemas distribuídos e aplicativos web em tempo real por meio de ferramentas como Phoenix LiveView. Os comentaristas contrastam isso com ecossistemas como C#, Node.js e Go, debatendo se a comunidade menor do Elixir, o modelo de implantação e as ferramentas compensam a troca em relação a stacks e frameworks mais mainstream, como Entity Framework ou Hot Chocolate. Um tema recorrente é a tensão entre a tipagem dinâmica do Elixir e o desejo por garantias estáticas mais fortes, com muitos acolhendo o sistema de tipos em desenvolvimento, ao mesmo tempo em que valorizam o pattern matching, a imutabilidade e os pontos fortes operacionais da BEAM.
Principais Forças do Elixir (BEAM/OTP)
- Muitos veem o valor real não na sintaxe, mas nos processos BEAM, no OTP, nas árvores de supervisão e na passagem de mensagens.
- Descrito como “como k8s sem as partes complicadas” em termos de confiabilidade, distribuição e tolerância a falhas.
- Jobs em segundo plano, processos de longa duração e cargas de trabalho heterogêneas no mesmo cluster são citados como “superpoderes”, especialmente para equipes pequenas.
Concorrência e Trabalho em Segundo Plano
- Os processos baratos do Elixir tornam seguro manter requisições HTTP abertas por mais tempo, fazer IO bloqueante ou distribuir chamadas HTTP sem sistemas de jobs separados.
- Alguns preferem uma separação rígida entre computação web e em segundo plano com filas e monitoramento externo; outros argumentam que o Elixir permite obter retries robustos, back-pressure e supervisão com muito פחות infraestrutura.
- Bibliotecas como Oban, Broadway, Flow e Task são destacadas por oferecerem múltiplos níveis de abstração para trabalho concorrente.
LiveView e LiveBook
- O LiveView é elogiado por tornar fáceis interfaces reativas e interfaces “ligeiramente JS”, reutilizando validação e estado do backend.
- Alguns dizem que ele é direto uma vez que você entende o modelo mental (websockets + diffs + processos com estado).
- Outros acham que UIs não triviais podem “bater de frente” com o framework, se preocupam com a dependência de sockets persistentes e consideram que ele ainda está amadurecendo para apostas de startup.
Tipagem Dinâmica vs. Estática
- O fio é dominado por debates sobre tipos.
- Defensores de tipos estáticos sentem falta de garantias em tempo de compilação, segurança em refatorações, melhor assistência do IDE e formas de dados mais claras; alguns dizem que a falta de tipos acabou tornando o Elixir desagradável em bases de código grandes.
- Defensores do modelo atual do Elixir apontam para pattern matching, imutabilidade, specs + Dialyzer e inspeção em tempo de execução como suficientes para muitos domínios.
- Vários posts observam que um sistema de tipos gradual para Elixir está em desenvolvimento ativo; Gleam é frequentemente mencionado como uma alternativa BEAM tipada.
Ecossistema, Ferramentas e Adoção
- Alguns argumentam que os ecossistemas Elixir/Erlang são “bem estabelecidos” e poderosos; outros acham as ferramentas (suporte de IDE, documentação de Phoenix/Ecto) ásperas em comparação com grandes ecossistemas.
- Suporte no Windows e integração com k8s ou outros runtimes são relatados como pontos de dor por alguns.
- O debate sobre “nenhuma startup de sucesso” é contraposto com exemplos de produtos conhecidos e grandes empresas usando Elixir/BEAM, embora às vezes apenas em partes de seu stack.
Contratação e Dinâmica de Carreira
- Empresas frequentemente contratam engenheiros fortes sem experiência prévia em Elixir e os treinam, devido a um pequeno pool de experientes e a um alto interesse.
- Outros dizem que as vagas muitas vezes exigem Elixir prévio, o que dificulta entrar sem projetos paralelos substanciais.