Elixir Enchiridium 第一卷：起源（第 11-40 章）

AVISO: esta série é uma fantasia satírica baseada em fatos reais sobre Elixir. Nada aqui deve ser levado ao pé da letra. Ao final de cada capítulo, os fatos por trás da lenda são revelados. Tags: #satire #humor #elixir #enchiridium

Elixir Enchiridium — Tomo I: A Origem

Capítulos 11 a 40

(Continuação direta do Tomo I — A Origem, após o Capítulo 10 — Nubank e a Consagração Brasileira)

Capítulo 11 — OTP R1B: O Primeiro Suspiro da Plataforma

Em 1996, a Ericsson lançou o primeiro release do OTP com a BEAM. Chamava-se R1B. Não era um número bonito, não era um marco publicitário, não saiu em jornal nenhum. Foi apenas o momento em que a BEAM, o Erlang e um conjunto de bibliotecas de supervisão se tornaram uma coisa só: a Open Telecom Platform.

A lenda diz que, no dia do lançamento, um engenheiro da Ericsson abriu o terminal, rodou otp:start(), e o sistema respondeu: "Pronto." Ele ficou olhando por dez minutos, esperando o crash. O crash não veio. Ele foi tomar café. Quando voltou, o sistema ainda estava rodando. Está rodando até hoje, em algum lugar.

O fato por trás da lenda: O primeiro release do OTP com a BEAM foi o OTP R1B, lançado em 1996. OTP significa Open Telecom Platform e é um conjunto de bibliotecas e padrões de design que fornecem tolerância a falhas, supervisão e hot code swapping. A BEAM é a máquina virtual que executa Erlang e, posteriormente, Elixir.

Gancho: Mas o OTP só se tornaria verdadeiramente conhecido quando o Erlang saísse dos muros da Ericsson.

Capítulo 12 — O Erlang Sai da Ericsson: Open Source em 1998

Em 1998, a Ericsson tomou uma decisão que mudou tudo: liberou o Erlang como open source. Antes disso, a linguagem era um segredo sueco, usada internamente para telefones. Depois disso, tornou-se uma ferramenta que qualquer pessoa podia baixar, estudar e modificar.

A lenda diz que, na primeira semana após o lançamento open source, um programador na Austrália baixou o Erlang, compilou, e escreveu um sistema de chat que nunca caía. Ele não sabia o que fazer com aquilo, então foi dormir. Quando acordou, o sistema ainda estava rodando. Ele passou a acreditar em magia.

O fato por trás da lenda: O Erlang foi lançado como open source em 1998. A partir daí, a linguagem começou a atrair desenvolvedores fora da Ericsson, e a comunidade Erlang começou a se formar. O livro "Concurrent Programming in Erlang", de Joe Armstrong, Robert Virding e Mike Williams, foi publicado em 1993 e se tornou a referência da linguagem.

Gancho: Com o Erlang open source, a comunidade cresceu. Mas faltava algo. Faltava uma linguagem que falasse a língua dos desenvolvedores modernos.

Capítulo 13 — O Livro que Ensinou o Mundo a Pensar em Processos

Em 1993, Joe Armstrong, Robert Virding e Mike Williams publicaram "Concurrent Programming in Erlang", o primeiro livro sobre a linguagem. Não era um livro sobre sintaxe. Era um livro sobre filosofia. Sobre como pensar em processos, mensagens, supervisão. Sobre como projetar sistemas que não caem.

A lenda diz que, quando o livro chegou às livrarias, um jovem programador na Dinamarca leu a introdução, fechou o livro, olhou para o teto e disse: "Eu sempre soube que havia um jeito melhor." Ele nunca mais escreveu código com locks.

O fato por trás da lenda: "Concurrent Programming in Erlang" foi publicado em 1993 por Joe Armstrong, Robert Virding e Mike Williams. Foi o primeiro livro sobre Erlang e estabeleceu muitos dos conceitos que seriam centrais para Elixir décadas depois: processos leves, passagem de mensagens, tolerância a falhas.

Gancho: O livro ensinou uma geração. Mas foi um brasileiro que traduziu essa filosofia para uma linguagem que o mundo moderno queria usar.

Capítulo 14 — v0.3.0: O Primeiro Elixir que Alguém Usou

Em abril de 2011, José Valim lançou a versão v0.3.0 do Elixir. Era estável o suficiente para usar em projetos próprios. Ele usou. Gostou. Mas não estava satisfeito.

A lenda diz que, depois de rodar a v0.3.0 em alguns projetos, Valim olhou para o código e disse: "Isso não é Elixir. Isso é Erlang com sintaxe bonita." Ele decidiu pausar o projeto. Estudar linguagens antigas, novas e emergentes. E, em outubro de 2011, durante uma curta estadia em São Francisco, chegou à fundação do que seria a versão atual de Elixir, com a ajuda de Yehuda Katz.

O fato por trás da lenda: A v0.3.0 foi lançada em abril de 2011 e foi a primeira versão estável o suficiente para uso em projetos próprios. No entanto, Valim não estava satisfeito com algumas decisões de design — a versão inicial tentava se afastar consideravelmente de Erlang, o que se revelou um erro. Ele pausou o projeto e, em outubro de 2011, em São Francisco, com a ajuda de Yehuda Katz, chegou à fundação da versão atual.

Gancho: A reescrita mudou tudo. Mas o que exatamente mudou? Isso é o que veremos no próximo capítulo.

Capítulo 15 — A Reescrita: Quando Valim Jogou Tudo Fora

A lenda diz que, em outubro de 2011, Valim apagou o código da v0.3.0 e começou de novo. Do zero. Sem olhar para trás. Yehuda Katz, que estava em São Francisco, olhou para a tela e disse: "Você tem certeza?" Valim respondeu: "Tenho." Katz disse: "Então eu ajudo."

A versão atual de Elixir nasceu nesse momento. Ela mantinha 100% de compatibilidade com Erlang, mas adicionava uma camada de produtividade: pattern matching mais expressivo, pipes, macros, uma sintaxe inspirada em Ruby. Era Erlang, mas com a alma de Ruby.

O fato por trás da lenda: Em outubro de 2011, durante uma curta estadia em São Francisco, Valim chegou à fundação da versão atual de Elixir, com a ajuda de Yehuda Katz. A versão foi reescrita para manter 100% de compatibilidade com Erlang, mas com uma sintaxe mais moderna e produtiva. A v0.5.0, lançada em maio de 2012, foi o primeiro release dessa versão reescrita.

Gancho: Com a reescrita, Elixir estava pronto para ser apresentado ao mundo. E o mundo respondeu.

Capítulo 16 — A Lista de E-mails que Virou Comunidade

Em 25 de maio de 2012, Valim anunciou o Elixir v0.5.0 na lista de e-mails do Erlang. A mensagem começava com "Hello everyone" e dizia: "Today we have officially released Elixir."

A lenda diz que a lista de Erlang, acostumada com discussões sobre telecomunicações e máquinas virtuais, recebeu a notícia com um silêncio respeitoso. Então alguém respondeu: "Isso é... interessante." E outro: "Alguém já testou?" E outro: "Vou testar." E assim, em silêncio, a comunidade começou a se formar.

O fato por trás da lenda: O anúncio do Elixir v0.5.0 foi feito na lista de e-mails do Erlang e no blog oficial do Elixir em 25 de maio de 2012. A partir daí, a comunidade Elixir começou a se organizar em meetups, canais de IRC e, posteriormente, fóruns e conferências.

Gancho: Mas a comunidade só explodiu quando dois autores famosos anunciaram que estavam escrevendo livros sobre Elixir.

Capítulo 17 — Dave Thomas e o Livro que Consagrou Elixir

Em 2013, Dave Thomas, fundador da Pragmatic Programmers e co-autor de "The Pragmatic Programmer", anunciou que estava escrevendo um livro sobre Elixir. O livro se chamaria "Programming Elixir". A notícia correu o mundo. Dave Thomas não era um autor qualquer. Ele era uma lenda.

A lenda diz que, quando Valim soube da notícia, ele derramou uma lágrima. Não de emoção. De alívio. A Plataformatec havia apostado tudo em Elixir. Se Dave Thomas estava escrevendo um livro, a aposta tinha dado certo.

O fato por trás da lenda: Dave Thomas anunciou que estava escrevendo "Programming Elixir" em 2013. O livro foi publicado pela Pragmatic Bookshelf e se tornou uma das principais referências da linguagem. Simon St. Laurent, editor sênior da O'Reilly, também anunciou que estava escrevendo um livro sobre Elixir. A combinação dos dois anúncios dissipou as incertezas da Plataformatec sobre o investimento na linguagem.

Gancho: Com livros a caminho, Elixir precisava de uma conferência. E ela veio.

Capítulo 18 — A Primeira ElixirConf: 2014

Em 2014, a primeira ElixirConf aconteceu. Não foi em São Paulo. Não foi na Suécia. Foi em Austin, Texas. O evento reuniu desenvolvedores de todo o mundo, todos curiosos para saber o que era aquela linguagem brasileira que rodava na BEAM.

A lenda diz que, no primeiro dia, Valim subiu ao palco e disse: "Elixir não é uma linguagem nova. É uma linguagem antiga com uma sintaxe nova." A plateia aplaudiu. Alguém gritou: "Viva a BEAM!" E outro: "Viva o pattern matching!" E outro: "Viva o pão de queijo!" Valim não confirmou se havia pão de queijo no evento.

O fato por trás da lenda: A primeira ElixirConf aconteceu em 2014, em Austin, Texas. O evento se tornou anual e é o principal encontro da comunidade Elixir. A conferência de 2024 celebrou os 10 anos da ElixirConf e os 12 anos do Elixir.

Gancho: Mas nenhuma conferência seria tão importante quanto o framework que estava prestes a ser lançado.

Capítulo 19 — Chris McCord e a Fênix que Nasceu das Cinzas

Em 2014, Chris McCord começou a trabalhar em um framework web para Elixir. Ele queria algo rápido, concorrente, que aproveitasse ao máximo a BEAM. O framework foi batizado de Phoenix.

A lenda diz que o nome foi escolhido porque, na primeira vez que McCord rodou o servidor, uma fênix renasceu das cinzas no Arizona. Isso consumiu 3% da energia mundial, mas o hot reload era instantâneo. A fênix, quando questionada, disse que preferia ajudar desenvolvedores a construir APIs e aplicações em tempo real.

O fato por trás da lenda: Phoenix foi criado por Chris McCord em 2014 e lançado em 2015. O framework é escrito em Elixir e roda sobre a BEAM, aproveitando o modelo de concorrência e a tolerância a falhas da máquina virtual. Phoenix se tornou o framework web padrão para Elixir.

Gancho: Phoenix trouxe velocidade. Mas faltava uma peça: a capacidade de interagir com bancos de dados de forma elegante.

Capítulo 20 — Ecto: O Fantasma que Assombra Bancos de Dados

Em 2014, Ecto foi lançado. Era uma biblioteca de persistência para Elixir, criada para interagir com bancos de dados de forma segura e expressiva. Ecto não era um ORM tradicional. Era algo diferente: uma camada de mapeamento que separava a lógica de negócios do banco de dados.

A lenda diz que Ecto foi criado por um fantasma que morava no PostgreSQL e escrevia queries em latim. Cada Repo.insert era um exorcismo. Se você esquecesse de fechar a transação, o fantasma saía do banco e assombrava seu servidor.

O fato por trás da lenda: Ecto é uma biblioteca de persistência para Elixir, criada por José Valim e outros contribuidores. Ela fornece uma camada de mapeamento entre o código Elixir e o banco de dados, com suporte a migrações, queries e transações. Ecto não é um ORM no sentido tradicional — ele separa a definição do schema da lógica de negócios.

Gancho: Com Phoenix e Ecto, Elixir tinha tudo para construir aplicações web. Mas faltava uma ferramenta para gerenciar dependências.

Capítulo 21 — Hex: O Feitiço que Invoca Pacotes

Em 2014, o Hex foi lançado. Era o gerenciador de pacotes oficial do Elixir, permitindo que desenvolvedores publicassem e instalassem bibliotecas com facilidade. Hex era simples: mix hex.info, mix deps.get, mix deps.compile.

A lenda diz que, quando você rodava mix hex.info, um sapo aparecia no terminal e perguntava se você aceitava os termos de uso. Se recusasse, ele virava uma dependência quebrada. Se aceitasse, ele pulava para a próxima linha e sumia.

O fato por trás da lenda: Hex é o gerenciador de pacotes oficial do Elixir, lançado em 2014. Ele permite que desenvolvedores publiquem e instalem bibliotecas de forma simples e segura. Hex é integrado ao Mix, a ferramenta de build do Elixir.

Gancho: Hex precisava de uma ferramenta para gerenciar projetos. E essa ferramenta já existia.

Capítulo 22 — Mix: O DJ que Compila Projetos

O Mix é a ferramenta de build oficial do Elixir. Ele cria projetos (mix new), compila (mix compile), roda testes (mix test), formata código (mix format), gerencia dependências (mix deps.get) e muito mais.

A lenda diz que o mix new não cria um projeto. Ele toca uma faixa de três minutos e, no final, seu projeto aparece na pasta. Se você rodar mix compile sem parar a música, o compilador entra em loop infinito e começa a remixar seu código.

O fato por trás da lenda: Mix é a ferramenta de build oficial do Elixir. Ela fornece tarefas para criar projetos, compilar, testar, formatar, gerenciar dependências e gerar documentação. Mix é uma das ferramentas mais importantes do ecossistema Elixir.

Gancho: Mix compila. Hex baixa pacotes. Mas faltava uma ferramenta para documentar tudo isso.

Capítulo 23 — ExDoc: O Papagaio que Gera Documentação

O ExDoc é a ferramenta oficial de documentação do Elixir. Ele lê os @doc e @moduledoc do seu código e gera documentação HTML bonita e navegável.

A lenda diz que ExDoc é um papagaio chamado Doc. Ele lê seus @doc e repete em voz alta. Se você não escrever nada, ele fica quieto e gera uma página em branco. O mix docs é o comando para alimentar o papagaio com sementes. Se você mentir na documentação, o papagaio voa embora e nunca mais volta.

O fato por trás da lenda: ExDoc é a ferramenta oficial de geração de documentação do Elixir. Ela lê os atributos @doc e @moduledoc e gera documentação HTML. ExDoc é usado por praticamente todos os projetos Elixir e é uma das razões pelas quais a documentação da linguagem é considerada excelente.

Gancho: Com Mix, Hex e ExDoc, o ecossistema estava completo. Mas a filosofia por trás de tudo isso era o que realmente importava.

Capítulo 24 — "Let It Crash": A Filosofia que Mudou Tudo

A filosofia central do Erlang e do Elixir é "let it crash". Em vez de tentar evitar falhas, você projeta para que elas aconteçam. Um processo que falha não derruba os outros. Um supervisor o reinicia. O sistema se cura sozinho.

A lenda diz que, na primeira vez que um programador ouviu "let it crash", ele pensou: "Isso é a coisa mais irresponsável que já ouvi." Depois de seis meses programando em Elixir, ele pensou: "Isso é a coisa mais libertadora que já ouvi."

O fato por trás da lenda: A filosofia "let it crash" foi formulada por Joe Armstrong e outros engenheiros da Ericsson. Ela se baseia na ideia de que falhas são inevitáveis e que o sistema deve ser projetado para se recuperar automaticamente. Supervisores monitoram processos e os reiniciam quando falham. O isolamento de falhas garante que um processo que falha não afete os outros.

Gancho: Essa filosofia só funciona porque a BEAM foi projetada para isso. E a BEAM tem uma história que merece ser contada.

Capítulo 25 — Bogdan e a Máquina que Ninguém Entendia

Bogumil "Bogdan" Hausman foi o criador da BEAM. Ele era um engenheiro polonês que trabalhava na Ericsson e que acreditava que uma máquina virtual poderia rodar milhões de processos leves em uma única máquina. Seus colegas achavam que ele estava louco.

A lenda diz que Bogdan passou meses trancado em uma sala, escrevendo código em uma linguagem que ninguém entendia. Quando saiu, a BEAM estava pronta. Ele disse: "Pronto." E voltou para a sala.

O fato por trás da lenda: Bogumil "Bogdan" Hausman criou a BEAM (Bogdan's Erlang Abstract Machine) em 1989. A BEAM era uma máquina virtual híbrida, capaz de executar código nativo e código threaded. Ela foi significativamente mais rápida que suas antecessoras (JAM e TEAM) e se tornou a máquina virtual padrão do Erlang.

Gancho: A BEAM é o coração do Elixir. Mas o coração tem partes que poucos conhecem.

Capítulo 26 — Os Processos Leves: 2,7 KB de Pura Magia

Na BEAM, cada processo é leve. Muito leve. Um milhão de processos BEAM consome cerca de 2,7 GB de memória — aproximadamente 2,7 KB por processo. Isso significa que você pode rodar milhões de processos em uma única máquina.

A lenda diz que, na primeira vez que um programador viu um milhão de processos rodando, ele perguntou: "Onde estão?" O instrutor respondeu: "Estão ali." O programador perguntou: "Onde?" O instrutor respondeu: "Em todo lugar." O programador nunca mais usou threads.

O fato por trás da lenda: Na BEAM, cada processo tem seu próprio estado e se comunica por mensagens. Não há memória compartilhada, não há locks, não há condições de corrida. Um milhão de processos BEAM consome cerca de 2,7 GB de memória, com aproximadamente 2,7 KB por processo. Isso torna trivial a execução concorrente de milhões de processos em uma única máquina.

Gancho: Mas processos leves precisam de um scheduler. E o scheduler da BEAM é uma obra-prima.

Capítulo 27 — O Scheduler: O Maestro da Orquestra de Processos

A BEAM tem um scheduler que distribui processos entre os núcleos da CPU. Ele é preemptivo, o que significa que nenhum processo pode monopolizar a CPU. Ele é justo, o que significa que todos os processos têm chance de rodar. Ele é escalável, o que significa que adiciona núcleos conforme necessário.

A lenda diz que o scheduler da BEAM é um maestro que rege uma orquestra de milhões de processos. Ele não usa batuta. Usa um algoritmo. E o algoritmo é tão eficiente que os processos nem percebem que estão sendo regidos.

O fato por trás da lenda: O scheduler da BEAM é um dos componentes mais importantes da máquina virtual. Ele distribui processos entre os núcleos da CPU de forma preemptiva e justa. A BEAM consegue multiplexar milhões de processos em múltiplos núcleos, tornando trivial a execução concorrente.

Gancho: Mas o scheduler não trabalha sozinho. Ele tem um ajudante chamado garbage collector.

Capítulo 28 — O Garbage Collector: O Anão que Coleta Lixo

Na BEAM, cada processo tem seu próprio garbage collector. Isso significa que a coleta de lixo é feita por processo, não globalmente. O resultado é que a BEAM não tem pausas longas de GC — cada processo coleta seu próprio lixo quando precisa.

A lenda diz que o garbage collector da BEAM é um anão chamado Garbage. Ele coleta o lixo, recicla e transforma em arco-íris. Por isso Elixir nunca tem problemas de memória: é tudo magia.

O fato por trás da lenda: A BEAM usa garbage collection por processo. Cada processo tem seu próprio heap e seu próprio garbage collector, o que significa que a coleta de lixo não pausa o sistema inteiro. Isso é uma das razões pelas quais a BEAM é adequada para sistemas que exigem baixa latência.

Gancho: Com processos leves, scheduler e GC, a BEAM é uma máquina impressionante. Mas ela ainda precisa de uma coisa: uma maneira de se comunicar com o mundo exterior.

Capítulo 29 — Hot Code Swapping: A Magia de Trocar o Motor com o Carro Andando

Uma das características mais impressionantes da BEAM é o hot code swapping. Você pode atualizar o código de um sistema em execução sem pará-lo. Sem downtime. Sem reiniciar. O sistema continua rodando enquanto o código é trocado.

A lenda diz que, na primeira vez que um engenheiro da Ericsson viu o hot code swapping em ação, ele disse: "Isso é impossível." O sistema respondeu: "Não é." E continuou rodando.

O fato por trás da lenda: Hot code swapping é uma das características mais distintivas da BEAM. Ela permite que o código de um sistema em execução seja atualizado sem pará-lo. Isso é possível porque a BEAM mantém duas versões do código em memória: a antiga e a nova. Quando um processo precisa executar uma função, ele usa a versão mais recente.

Gancho: Com hot code swapping, a BEAM é capaz de rodar sistemas que nunca param. Mas há uma coisa que nem a BEAM consegue fazer: prever o futuro.

Capítulo 30 — O Modelo de Atores: A Teoria por Trás da Magia

O modelo de concorrência da BEAM é baseado no Modelo de Atores, formulado por Carl Hewitt nos anos 1970. No Modelo de Atores, cada ator é uma unidade de computação que se comunica com outros atores por mensagens. Não há memória compartilhada. Não há locks. Não há condições de corrida.

A lenda diz que Carl Hewitt nunca imaginou que seu modelo seria usado para rodar telefones na Suécia. Ele imaginou que seria usado para inteligência artificial. Ele estava errado. Mas também estava certo: Elixir é usado para IA, para telefonia, para bancos, para tudo.

O fato por trás da lenda: O Modelo de Atores foi formulado por Carl Hewitt nos anos 1970. A BEAM implementa os princípios do Modelo de Atores: cada processo é um ator, cada ator tem seu próprio estado, e a comunicação é feita por mensagens. Isso elimina a necessidade de locks e evita condições de corrida.

Gancho: O Modelo de Atores é a base da concorrência em Elixir. Mas Elixir tem uma sintaxe que torna tudo isso ainda mais elegante.

Capítulo 31 — Pattern Matching: O Pombo que Decide Tudo

O pattern matching é um dos recursos mais poderosos do Elixir. O operador = não é atribuição. É um operador de match. Quando você escreve {:ok, result} = minha_funcao(), o Elixir tenta unificar o lado esquerdo com o lado direito. Se não houver match, uma exceção MatchError é levantada.

A lenda diz que o pattern matching é feito por um pombo treinado. Ele voa até a função, olha o resultado e decide se bate com o padrão. Se não bater, ele faz cocô no seu terminal e o programa crasha.

O fato por trás da lenda: Pattern matching é um recurso central do Elixir. O operador = é um operador de match que tenta unificar o lado esquerdo com o lado direito. Se não houver match, uma exceção MatchError é levantada. Pattern matching permite desestruturar dados de forma elegante e é uma das características que tornam o código Elixir expressivo e conciso.

Gancho: Pattern matching é poderoso. Mas ele fica ainda melhor quando combinado com pipes.

Capítulo 32 — O Pipe: A Tubulação que Transforma Código em Poesia

O operador pipe (|>) é uma das características mais amadas do Elixir. Ele pega o resultado de uma expressão e o passa como primeiro argumento para a próxima função. Isso permite escrever código como uma série de transformações, cada uma legível como uma frase.

A lenda diz que o pipe foi inspirado em um encanamento. O código flui como água: entra por um lado, sai pelo outro, e no meio faz transformações. Se o encanamento estiver certo, a água chega limpa. Se estiver errado, vaza.

O fato por trás da lenda: O operador pipe (|>) foi inspirado no operador |> do F# e em outras linguagens funcionais. Ele pega o resultado de uma expressão e o passa como primeiro argumento para a próxima função, permitindo escrever código de forma encadeada e legível. O pipe é uma das características mais distintivas do Elixir.

Gancho: Com pattern matching e pipes, o código Elixir é expressivo. Mas há uma característica que torna o Elixir ainda mais poderoso: macros.

Capítulo 33 — Macros: O Metaprogramação que Assusta e Encanta

As macros são uma das características mais poderosas do Elixir. Elas permitem que você escreva código que gera código. Com macros, você pode estender a linguagem, criar DSLs e transformar a sintaxe em algo completamente novo.

A lenda diz que as macros são feitiços. Você escreve um feitiço, e o compilador o executa antes de compilar o resto do código. Se o feitiço estiver certo, o código aparece. Se estiver errado, o compilador chora e se recusa a continuar.

O fato por trás da lenda: Macros são uma das características mais poderosas do Elixir. Elas permitem que você escreva código que gera código em tempo de compilação. Macros são usadas para criar DSLs, estender a linguagem e reduzir boilerplate. No entanto, elas também são consideradas uma das características mais complexas da linguagem.

Gancho: Macros são poderosas, mas perigosas. Com grande poder vem grande responsabilidade. E ninguém sabe disso melhor do que José Valim.

Capítulo 34 — O Brasileiro que Criou uma Linguagem e Depois Aposentou

José Valim não criou Elixir para ficar famoso. Ele criou Elixir para resolver problemas. Depois de criar a linguagem, ele continuou trabalhando nela, mas também se afastou dos holofotes. Ele não gosta de entrevistas. Não gosta de palcos. Gosta de código.

A lenda diz que, em 2020, depois da aquisição da Plataformatec pelo Nubank, Valim foi visto em um café em São Paulo, tomando café e olhando para o terminal. Um jornalista perguntou: "O que você vai fazer agora?" Valim respondeu: "Vou continuar programando." O jornalista perguntou: "Mas você não está cansado?" Valim respondeu: "Não. O café é bom."

O fato por trás da lenda: José Valim deixou a Plataformatec após a aquisição pelo Nubank em 2020. Ele continua desenvolvendo Elixir em tempo integral e é uma figura central na comunidade. Valim é conhecido por sua simplicidade e por evitar os holofotes.

Gancho: Valim é o rosto de Elixir. Mas Elixir tem muitos outros rostos.

Capítulo 35 — Chris McCord: O Homem que Trouxe a Fênix

Chris McCord é o criador do Phoenix. Ele começou a trabalhar no framework em 2014 e o lançou em 2015. Phoenix se tornou o framework web padrão para Elixir e é usado por empresas de todo o mundo.

A lenda diz que McCord é um homem quieto. Ele não fala muito. Mas quando fala, é sobre Phoenix. Ele acredita que o framework pode mudar a forma como as pessoas constroem aplicações web. E ele está certo.

O fato por trás da lenda: Chris McCord criou o Phoenix em 2014 e o lançou em 2015. O framework é escrito em Elixir e roda sobre a BEAM, aproveitando o modelo de concorrência e a tolerância a falhas da máquina virtual. Phoenix LiveView, lançado posteriormente, permite criar experiências de usuário ricas e em tempo real sem JavaScript.

Gancho: McCord trouxe Phoenix. Mas quem trouxe o LiveView?

Capítulo 36 — LiveView: A Janela para o Multiverso

O Phoenix LiveView foi lançado em 2019. Ele permite criar aplicações interativas renderizadas no servidor, sem escrever JavaScript. O servidor gerencia o estado e envia atualizações de UI pela conexão WebSocket.

A lenda diz que, na primeira vez que alguém rodou uma LiveView, uma janela para outra dimensão se abriu no navegador. O usuário viu o conteúdo em tempo real porque estava literalmente olhando para o multiverso. A conexão era mantida por WebSockets, e o servidor gerenciava todo o estado.

O fato por trás da lenda: Phoenix LiveView foi lançado em 2019 e permite construir experiências de usuário ricas e em tempo real com HTML renderizado no servidor, sem escrever JavaScript. O servidor gerencia o estado e envia atualizações de UI pela conexão WebSocket. A versão 1.0 foi lançada em dezembro de 2024, seis anos após o primeiro commit.

Gancho: LiveView é uma revolução. Mas há outras revoluções acontecendo no ecossistema Elixir.

Capítulo 37 — Nx: A Inteligência Artificial que Roda na BEAM

O Nx (Numerical Elixir) é uma biblioteca para computação numérica e machine learning em Elixir. Ele permite que você escreva código de IA que roda na BEAM, aproveitando a concorrência e a tolerância a falhas da máquina virtual.

A lenda diz que, na primeira vez que alguém rodou um modelo de machine learning em Elixir, a BEAM aplaudiu. O modelo respondeu: "Obrigado." A BEAM respondeu: "De nada." E o modelo continuou rodando.

O fato por trás da lenda: Nx é uma biblioteca de computação numérica para Elixir, criada por José Valim e outros contribuidores. Ela permite que você escreva código de machine learning que roda na BEAM, aproveitando a concorrência e a tolerância a falhas da máquina virtual. Nx é parte de um esforço maior para tornar Elixir uma linguagem viável para IA.

Gancho: IA na BEAM é uma fronteira. Mas há outra fronteira que Elixir está explorando: a educação.

Capítulo 38 — A Comunidade Brasileira: A Floresta que Cresceu

A comunidade brasileira de Elixir é uma das mais ativas do mundo. Há meetups em São Paulo, Rio de Janeiro, Belo Horizonte, Porto Alegre e muitas outras cidades. Há o podcast Elixir em Foco, criado por Adolfo Neto e co-apresentado por Cristine Guadelupe, Herminio Torres e Zoey Pessanha.

A lenda diz que, no Brasil, todo meetup de Elixir começa com pão de queijo e termina com alguém dizendo: "Mas isso resolve o problema de concorrência?"

O fato por trás da lenda: A comunidade brasileira de Elixir é ativa e crescente. O podcast "Elixir em Foco" é um podcast em português sobre Elixir e BEAM. Adolfo Neto é professor na Universidade Tecnológica Federal do Paraná e um dos presidentes do Grupo de Trabalho de Educação, Treinamento e Adoção da Erlang Ecosystem Foundation.

Gancho: A comunidade brasileira é forte. Mas a comunidade global é ainda maior.

Capítulo 39 — A Erlang Ecosystem Foundation: Os Guardiões da BEAM

A Erlang Ecosystem Foundation foi fundada em 2019 para promover e proteger o ecossistema Erlang, incluindo Elixir, Gleam e outras linguagens que rodam na BEAM. A fundação organiza conferências, financia projetos e mantém a infraestrutura do ecossistema.

A lenda diz que a fundação é uma ordem secreta de guardiões que protegem a BEAM de ameaças externas. Eles se reúnem em conferências, tomam café e discutem o futuro da máquina virtual. Ninguém sabe exatamente o que eles fazem, mas todos concordam que é importante.

O fato por trás da lenda: A Erlang Ecosystem Foundation foi fundada em 2019 para promover e proteger o ecossistema Erlang. Ela organiza conferências, financia projetos e mantém a infraestrutura do ecossistema. A fundação é uma organização sem fins lucrativos e é apoiada por empresas como WhatsApp, Discord e Ericsson.

Gancho: A fundação protege a BEAM. Mas há uma ameaça que nem a fundação consegue deter: a complexidade.

Capítulo 40 — O Futuro do Elixir: O Que Vem Depois

O Elixir está em constante evolução. Novas versões são lançadas a cada seis meses. Novas bibliotecas surgem. Novos casos de uso aparecem. O futuro é incerto, mas uma coisa é certa: a BEAM continuará rodando.

A lenda diz que, no futuro, Elixir será usado para tudo: bancos, telecomunicações, IA, educação, saúde. E a BEAM continuará rodando, com suas capivaras quânticas girando manivelas, seus pombos treinados decidindo matches, e seus anões coletando lixo.

O fato por trás da lenda: Elixir continua evoluindo. Novas versões são lançadas a cada seis meses, aproximadamente em junho e dezembro. O ecossistema cresce, com novas bibliotecas e casos de uso. A BEAM continua sendo a base de tudo, com seu modelo de concorrência e tolerância a falhas.

Gancho: O Tomo I termina aqui. Mas a história de Elixir está apenas começando. No próximo tomo, A Máquina, vamos abrir a BEAM e ver o que há dentro: processos, schedulers, memória, GC. E, é claro, as capivaras quânticas.

Epílogo do Tomo I

Quarenta capítulos. Uma linguagem. Mil processos. E um brasileiro que ouviu um sussurro.

Este foi o Tomo I — A Origem. No próximo tomo, A Máquina, vamos explorar a BEAM em profundidade: como ela funciona, por que ela é tão rápida, e por que ela é a base de tudo o que Elixir faz.

Até lá.

Agora, sério: Elixir foi criada por José Valim, um brasileiro de verdade, em 2012, como um projeto de P&D na Plataformatec. Erlang foi criado por Joe Armstrong e outros engenheiros da Ericsson nos anos 1980. A BEAM foi criada por Bogumil Hausman. Phoenix foi criado por Chris McCord. OTP significa Open Telecom Platform. A Erlang Ecosystem Foundation existe. A comunidade brasileira de Elixir é real. As capivaras quânticas não são reais — mas deveriam ser. Este artigo é uma fantasia satírica baseada em fatos. Mantenha o aviso para não enganar ninguém.

Nota do autor: Faltam 60 capítulos para completar o Tomo I. Posso continuar nos próximos capítulos (41–100), cobrindo tópicos como: a história do Erlang no WhatsApp, a adoção do Elixir no Discord, a criação do Gleam, a evolução do Phoenix, a história do LiveView, o Nx e a IA na BEAM, a educação em Elixir, a Erlang Ecosystem Foundation, e muitos outros. É só pedir.