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 41 a 60
(Continuação direta do Tomo I — A Origem, após o Capítulo 40 — O Futuro do Elixir)
Capítulo 41 — WhatsApp: O Gigante que Ninguém Viu
Em 2009, dois ex-funcionários do Yahoo!, Jan Koum e Brian Acton, compraram um iPhone e começaram a programar. Eles queriam criar um aplicativo de mensagens que fosse simples, rápido e que não caísse. A lenda diz que, na primeira reunião, Koum olhou para Acton e disse: "Qual linguagem a gente usa?" Acton respondeu: "Erlang." Koum perguntou: "Por quê?" Acton respondeu: "Porque a gente não quer contratar 500 engenheiros." Koum achou razoável.
O WhatsApp foi construído em Erlang. Rodava na BEAM. Escalava como ninguém. Em 2014, quando o Facebook comprou o WhatsApp por US$ 19 bilhões, a empresa tinha apenas 32 engenheiros e servia 465 milhões de usuários. Cada servidor sustentava 2 milhões de conexões simultâneas.
A lenda diz que, no dia da aquisição, Mark Zuckerberg ligou para Koum e perguntou: "Quantos engenheiros vocês têm?" Koum respondeu: "32." Zuckerberg ficou em silêncio por dez segundos. Depois disse: "Como assim?" Koum respondeu: "Erlang." Zuckerberg nunca mais subestimou a BEAM.
O fato por trás da lenda: O WhatsApp foi construído em Erlang e rodava na BEAM. A empresa foi comprada pelo Facebook em 2014 por US$ 19 bilhões, com apenas 32 engenheiros e 465 milhões de usuários. Cada servidor sustentava cerca de 2 milhões de conexões simultâneas. O WhatsApp entrega mais de 100 bilhões de mensagens por dia para mais de 2 bilhões de usuários.
Gancho: O WhatsApp provou que a BEAM funcionava em escala planetária. Mas havia outra empresa que também apostou tudo nela — e que ninguém esperava.
Capítulo 42 — Discord: O Chat que Escalou para 5 Milhões
Em 2015, Jason Citron e Stanislav Vishnevskiy fundaram o Discord. Queriam criar um aplicativo de chat para gamers. Mas havia um problema: os aplicativos de chat existentes não aguentavam a carga. Caíam. Travavam. Perdiam mensagens.
A lenda diz que, na primeira semana de desenvolvimento, Vishnevskiy olhou para o código e disse: "A gente precisa de uma linguagem que aguente milhões de conexões simultâneas." Citron perguntou: "Qual?" Vishnevskiy respondeu: "Elixir." Citron perguntou: "O que é isso?" Vishnevskiy respondeu: "É Erlang com sintaxe bonita." Citron confiou.
O Discord foi construído em Elixir. Rodava na BEAM. Cada servidor do Discord (chamado de "guild" internamente) rodava como um processo Elixir independente. Em 2017, o Discord atingiu 5 milhões de usuários simultâneos. Em 2020, rodava em cerca de 400 a 500 máquinas Elixir/Erlang, gerenciadas por uma equipe de 5 engenheiros.
A lenda diz que, na primeira vez que o Discord atingiu 5 milhões de usuários, Vishnevskiy olhou para o painel de monitoramento e disse: "A BEAM está feliz." A BEAM respondeu: "Sempre estive."
O fato por trás da lenda: O Discord foi construído em Elixir desde o início. Cada servidor (guild) roda como um processo Elixir independente. Em 2017, o Discord atingiu 5 milhões de usuários simultâneos. Em 2020, rodava em cerca de 400 a 500 máquinas Elixir/Erlang, gerenciadas por uma equipe de 5 engenheiros.
Gancho: WhatsApp e Discord provaram que a BEAM funciona em escala. Mas a BEAM não é só Elixir. Há outras linguagens rodando nela.
Capítulo 43 — Gleam: A Linguagem que Nasceu de uma Palestra
Em 2016, um desenvolvedor britânico chamado Louis Pilfold precisava fazer uma palestra sobre compiladores. Ele queria mostrar como construir uma linguagem. Então construiu uma. Chamou de Gleam.
A lenda diz que, no dia da palestra, Pilfold subiu ao palco, mostrou a linguagem, e alguém na plateia gritou: "Isso devia ser uma linguagem de verdade!" Pilfold pensou: "Talvez." E assim, o que era para ser um exemplo de palestra virou uma linguagem real, com tipos estáticos, que roda na BEAM.
Gleam é uma linguagem funcional, tipada estaticamente, que compila para Erlang (e para JavaScript). Ela foi projetada para ser "amigável" e "type-safe". Pilfold continuou desenvolvendo Gleam, e em 2024, a linguagem anunciou sua versão 1.0 na FOSDEM em Bruxelas.
A lenda diz que, quando Gleam 1.0 foi anunciada, a BEAM aplaudiu. Gleam respondeu: "Obrigado." A BEAM respondeu: "Bem-vinda à família."
O fato por trás da lenda: Gleam foi criada por Louis Pilfold em 2016, originalmente para uma palestra sobre compiladores. Ela foi posteriormente redesenhada e adaptada para se tornar uma linguagem real. Gleam é uma linguagem funcional, tipada estaticamente, que roda na BEAM. A versão 1.0 foi anunciada na FOSDEM em Bruxelas.
Gancho: Gleam é a prova de que a BEAM não é exclusiva de Erlang e Elixir. A família cresce.
Capítulo 44 — OTP 21: O Release que Mudou Tudo
Em 2018, a Ericsson lançou o OTP 21. Não era um release comum. Ele trouxe uma mudança que afetou todo o ecossistema: um novo sistema de logging. O logging do Erlang era notoriamente complicado. O OTP 21 introduziu o módulo logger, que permitia filtrar, formatar e redirecionar logs de forma muito mais simples.
A lenda diz que, no dia do lançamento, um engenheiro abriu o terminal, rodou logger:info("Olá") e o log apareceu formatado, com timestamp e nível de severidade. Ele chorou. Não de tristeza. De alívio.
O fato por trás da lenda: OTP 21 foi lançado em 2018 e introduziu o módulo logger, um novo sistema de logging que substituiu o antigo error_logger. O novo sistema é mais flexível e mais fácil de usar. OTP 21 também trouxe melhorias de performance e novas funcionalidades.
Gancho: O OTP 21 melhorou o logging. Mas o OTP 26 trouxe algo ainda mais importante: o compilador JIT.
Capítulo 45 — OTP 26 e o JIT: A BEAM Ficou Mais Rápida
Em 2023, a Ericsson lançou o OTP 26. A grande novidade era o compilador JIT (Just-In-Time). A BEAM sempre foi interpretada, mas com o JIT, ela passou a compilar código para linguagem de máquina em tempo de execução. O resultado foi um ganho de performance significativo.
A lenda diz que, na primeira vez que um programador rodou um benchmark com o OTP 26, ele olhou para o resultado e disse: "Isso está errado." Rodou de novo. O resultado era o mesmo. Ele olhou para o terminal e disse: "A BEAM ficou mais rápida." A BEAM respondeu: "Sempre fui. Agora vocês perceberam."
O fato por trás da lenda: OTP 26 foi lançado em 2023 e introduziu o compilador JIT (Just-In-Time) para a BEAM. O JIT compila código para linguagem de máquina em tempo de execução, resultando em ganhos significativos de performance. A BEAM sempre foi conhecida por sua concorrência e tolerância a falhas, mas o JIT a tornou mais competitiva em termos de velocidade bruta.
Gancho: O JIT tornou a BEAM mais rápida. Mas a BEAM sempre foi rápida o suficiente. O que importava era a concorrência.
Capítulo 46 — A Concorrência: O Segredo que Ninguém Entendia
A concorrência da BEAM é baseada em processos leves. Cada processo é isolado. Não compartilha memória. Comunica-se por mensagens. Um processo que falha não derruba os outros.
A lenda diz que, quando os primeiros programadores viram isso, eles disseram: "Isso não pode funcionar." Depois de rodar um milhão de processos, eles disseram: "Isso não deveria funcionar." Depois de rodar dez milhões, eles disseram: "Isso é magia." E a BEAM respondeu: "Não é magia. É engenharia."
O fato por trás da lenda: A BEAM adota um modelo de concorrência baseado em processos leves, implementando os princípios do Modelo de Atores. Cada processo tem seu próprio estado e troca mensagens com outros processos. Não há memória compartilhada, não há locks, não há condições de corrida. Isso torna trivial a execução concorrente de milhões de processos em uma única máquina.
Gancho: A concorrência da BEAM é impressionante. Mas ela só funciona porque a BEAM tem um scheduler que distribui processos de forma justa.
Capítulo 47 — O Scheduler Preemptivo: A Justiça da BEAM
O scheduler da BEAM é preemptivo. Isso significa que nenhum processo pode monopolizar a CPU. Ele é justo. Isso significa que todos os processos têm chance de rodar. Ele é escalável. Isso significa que ele adiciona núcleos conforme necessário.
A lenda diz que o scheduler da BEAM é um juiz que nunca dorme. Ele olha para cada processo e diz: "Você já rodou o suficiente. Próximo." Os processos obedecem. Se não obedecessem, o scheduler os interromperia.
O fato por trás da lenda: O scheduler da BEAM é preemptivo, justo e escalável. Ele distribui processos entre os núcleos da CPU de forma preemptiva, garantindo que nenhum processo monopolize a CPU. A BEAM consegue multiplexar milhões de processos em múltiplos núcleos.
Gancho: O scheduler é o coração da BEAM. Mas o coração tem um ajudante: o garbage collector.
Capítulo 48 — O Garbage Collector por Processo: A Pausa que Não Existe
Na maioria das linguagens, o garbage collector pausa o sistema inteiro. Na BEAM, não. 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.
A lenda diz que, na primeira vez que um programador viu isso, ele perguntou: "Onde está a pausa?" O instrutor respondeu: "Não tem." O programador perguntou: "Como assim?" O instrutor respondeu: "Cada processo coleta seu próprio lixo." O programador ficou em silêncio por dez minutos.
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. Isso significa que a coleta de lixo não pausa o sistema inteiro. É por isso que 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 maneira de se comunicar com o mundo exterior.
Capítulo 49 — Ports e NIFs: As Janelas para o Mundo
A BEAM não roda sozinha. Ela precisa se comunicar com o mundo exterior. Para isso, ela usa Ports e NIFs (Native Implemented Functions). Ports permitem que a BEAM se comunique com programas externos. NIFs permitem que a BEAM execute código nativo.
A lenda diz que, quando um programador descobriu os NIFs, ele disse: "Posso escrever código C e rodar na BEAM?" O instrutor respondeu: "Pode. Mas cuidado." O programador perguntou: "Por quê?" O instrutor respondeu: "Porque se o NIF travar, a BEAM inteira trava." O programador ficou em silêncio.
O fato por trás da lenda: Ports permitem que a BEAM se comunique com programas externos. NIFs permitem que a BEAM execute código nativo (C, C++, Rust, etc.). No entanto, NIFs são perigosos: se um NIF travar, ele pode derrubar a BEAM inteira. Por isso, a recomendação é usar Ports sempre que possível.
Gancho: Ports e NIFs são as janelas da BEAM. Mas há uma janela que é mais importante que todas as outras: o mix.
Capítulo 50 — Mix: A Ferramenta que Faz Tudo
O Mix é a ferramenta de build oficial do Elixir. Ele cria projetos, compila, roda testes, formata código, gerencia dependências e muito mais. É a ferramenta central do ecossistema Elixir.
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 51 — ExDoc: A Documentação que Vem do Código
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.
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.
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 52 — "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.
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 53 — 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 54 — 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.
Gancho: Mas processos leves precisam de um scheduler. E o scheduler da BEAM é uma obra-prima.
Capítulo 55 — 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.
Gancho: Mas o scheduler não trabalha sozinho. Ele tem um ajudante chamado garbage collector.
Capítulo 56 — 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 57 — 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.
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 58 — 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 59 — 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.
Gancho: Pattern matching é poderoso. Mas ele fica ainda melhor quando combinado com pipes.
Capítulo 60 — 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. E é isso que veremos no próximo bloco de capítulos.
Epílogo Parcial do Tomo I
Sessenta capítulos. Uma linguagem. Mil processos. E um brasileiro que ouviu um sussurro.
Ainda faltam 40 capítulos para completar o Tomo I. Nos próximos, vamos explorar: macros, o Nx e a IA na BEAM, a comunidade brasileira, a Erlang Ecosystem Foundation, a adoção do Elixir em empresas como a Helvetia, a evolução do Phoenix, o LiveView, a educação em Elixir com Adolfo Neto, e muitos outros tópicos.
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. O WhatsApp e o Discord usam Erlang/Elixir em escala. 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.
Top comments (0)