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 III: OTP
Capítulos 61 a 100
Capítulo 61 — DynamicSupervisor: A Babá que Contrata Sob Demanda
A lenda diz que o DynamicSupervisor é uma babá que não tem filhos fixos. Ela espera. Quando alguém precisa de um filho, ela contrata. Quando o filho morre, ela contrata outro. Ela nunca reclama. Ela nunca pergunta por quê. Ela apenas supervisiona.
A verdade é que o DynamicSupervisor é um supervisor que inicia filhos sob demanda, sem uma lista fixa definida na inicialização. Ele é usado quando o número de filhos não é conhecido antecipadamente, como em um servidor de jogos onde cada partida é um processo. A diferença fundamental é que o Supervisor tradicional inicia todos os filhos quando ele próprio inicia; o DynamicSupervisor inicia filhos quando start_child/2 é chamado.
A lenda diz que, quando um programador perguntou "Quantos filhos o DynamicSupervisor pode ter?", o instrutor respondeu: "Quantos você precisar." O programador perguntou: "E se eu precisar de um milhão?" O instrutor respondeu: "Ele contrata um milhão."
O fato por trás da lenda: DynamicSupervisor é um supervisor que inicia filhos sob demanda, sem lista fixa. Ele é usado quando o número de filhos não é conhecido antecipadamente. Supervisor tradicional inicia todos os filhos na inicialização; DynamicSupervisor inicia filhos quando start_child/2 é chamado.
Gancho: O DynamicSupervisor contrata. Mas há um processo que executa tarefas: a Task.
Capítulo 62 — Task: O Estagiário que Você Pode Matar Sem Culpa
A lenda diz que uma Task é um estagiário. Você contrata, dá uma tarefa, e espera. Se ele demorar, você grita. Se ele errar, você mata. Sem culpa. Sem remorso. Sem processo trabalhista. O estagiário não liga. Ele é um processo.
A verdade é que Task é um módulo para trabalhar com tarefas assíncronas. Uma Task é um processo que executa uma função e retorna o resultado. Task.async/1 inicia uma tarefa e retorna um %Task{}. Task.await/2 espera o resultado. Task.shutdown/2 mata a tarefa. Tasks são frequentemente usadas para paralelizar operações que podem ser executadas simultaneamente.
A lenda diz que, quando um programador perguntou "Posso matar a Task?", o instrutor respondeu: "Pode." O programador perguntou: "Ela se ofende?" O instrutor respondeu: "Ela é um processo. Processos não se ofendem."
O fato por trás da lenda: Task é um módulo para trabalhar com tarefas assíncronas. Uma Task é um processo que executa uma função e retorna o resultado. Task.async/1 inicia uma tarefa, Task.await/2 espera o resultado, e Task.shutdown/2 mata a tarefa.
Gancho: Tasks executam. Mas há um supervisor que as gerencia: o Task.Supervisor.
Capítulo 63 — Task.Supervisor: O RH que Contrata e Demite Estagiários
A lenda diz que o Task.Supervisor é o RH. Ele contrata Tasks. Ele demite Tasks. Ele mantém a paz. Se uma Task morre, ele contrata outra. Se todas morrem, ele chora. Mas depois contrata mais.
A verdade é que Task.Supervisor é um supervisor especializado para Tasks. Ele permite iniciar Tasks sob supervisão, o que significa que, se uma Task falhar, ela será reiniciada (ou não, dependendo da estratégia). Ele também permite async_nolink, que inicia uma Task sem link, útil para tarefas que podem falhar sem derrubar o processo pai.
A lenda diz que, quando um programador perguntou "Por que usar Task.Supervisor?", o instrutor respondeu: "Porque Tasks morrem." O programador perguntou: "E sem supervisor?" O instrutor respondeu: "Aí você chora junto."
O fato por trás da lenda: Task.Supervisor é um supervisor especializado para Tasks. Ele permite iniciar Tasks sob supervisão, e oferece async_nolink para tarefas que podem falhar sem derrubar o processo pai.
Gancho: Tasks e Supervisores trabalham juntos. Mas há um processo que guarda estado: o Agent.
Capítulo 64 — Agent: O Espião que Guarda Segredos em um Cofre
A lenda diz que um Agent é um espião. Ele guarda segredos em um cofre. Você pode pedir para ele atualizar o estado, mas ele só obedece se você usar a senha certa. Se você tentar ler o estado sem permissão, ele aciona o alarme e chama o supervisor.
A verdade é que Agent é uma abstração simples em torno de um GenServer que mantém estado. Ele é útil quando você precisa de um processo que guarda um estado simples e não justifica um GenServer completo. Agent.get/2 lê o estado, Agent.update/2 atualiza. Agents são frequentemente usados para contadores, caches simples e configurações compartilhadas.
A lenda diz que, quando um programador perguntou "Por que não usar um GenServer?", o instrutor respondeu: "Porque Agent é mais simples." O programador perguntou: "E se eu precisar de mais?" O instrutor respondeu: "Aí você usa GenServer."
O fato por trás da lenda: Agent é uma abstração simples em torno de um GenServer que mantém estado. É útil para contadores, caches simples e configurações compartilhadas. Quando a lógica fica complexa, GenServer é mais adequado.
Gancho: Agent guarda estado. Mas há uma coisa que registra processos: o Registry.
Capítulo 65 — Registry: A Lista Telefônica dos Processos
A lenda diz que o Registry é uma lista telefônica. Você registra um processo com um nome. Qualquer um pode procurar pelo nome e encontrar o processo. Se o processo morrer, ele é removido da lista. Se nascer, é adicionado. A lista nunca mente. A lista nunca erra.
A verdade é que Registry é um armazenamento de chaves e valores local, com suporte a particionamento e replicação. Ele é frequentemente usado para registrar processos com nomes, permitindo que outros processos os encontrem por nome em vez de por PID. Ao contrário do :global, o Registry é local ao nó (a menos que seja distribuído), e é mais eficiente para registros locais.
A lenda diz que, quando um programador perguntou "Por que não usar :global?", o instrutor respondeu: "Porque :global é global." O programador perguntou: "E o Registry?" O instrutor respondeu: "O Registry é local. E mais rápido."
O fato por trás da lenda: Registry é um armazenamento de chaves e valores local, com suporte a particionamento e replicação. É usado para registrar processos com nomes, permitindo que outros processos os encontrem por nome em vez de PID.
Gancho: Registry registra. Mas há uma coisa que distribui eventos: o Phoenix.PubSub.
Capítulo 66 — Phoenix.PubSub: O Megafone que Todos Ouvem
A lenda diz que o Phoenix.PubSub é um megafone. Você publica uma mensagem em um tópico. Todos os processos inscritos naquele tópico recebem a mensagem. Ninguém fica de fora. Ninguém ouve o que não devia. O megafone é justo.
A verdade é que Phoenix.PubSub é um sistema de publish-subscribe distribuído. Ele permite que processos se inscrevam em tópicos e recebam mensagens publicadas neles. Ele é usado pelo Phoenix para transmitir atualizações do LiveView, e pode ser usado em qualquer aplicação Elixir para comunicação entre processos. Ele funciona localmente e, com o adapter certo, em clusters.
A lenda diz que, quando um programador perguntou "Como o PubSub funciona?", o instrutor respondeu: "Você publica, eles ouvem." O programador perguntou: "E se ninguém ouvir?" O instrutor respondeu: "Aí a mensagem se perde. Mas alguém sempre ouve."
O fato por trás da lenda: Phoenix.PubSub é um sistema de publish-subscribe distribuído. Ele permite que processos se inscrevam em tópicos e recebam mensagens publicadas neles. É usado pelo Phoenix para transmitir atualizações do LiveView.
Gancho: PubSub distribui. Mas há uma coisa que persiste dados em disco: o DETS.
Capítulo 67 — DETS: O ETS que Fica no Disco
A lenda diz que o DETS é o irmão do ETS que mora no disco. Ele é mais lento. Ele é mais teimoso. Mas ele sobrevive a reinicializações. Se a BEAM morrer, o DETS continua lá. Esperando. Paciente.
A verdade é que dets (Disk Erlang Term Storage) é uma implementação de armazenamento de termos Erlang em disco. É semelhante ao ETS, mas persiste os dados em arquivo. DETS tem um limite de 2 GB por tabela e não é tão rápido quanto ETS, mas é útil para dados que precisam sobreviver a reinicializações.
A lenda diz que, quando um programador perguntou "Por que não usar ETS?", o instrutor respondeu: "Porque ETS esquece." O programador perguntou: "E o DETS?" O instrutor respondeu: "O DETS lembra."
O fato por trás da lenda: DETS (Disk Erlang Term Storage) é uma implementação de armazenamento de termos Erlang em disco. É semelhante ao ETS, mas persiste os dados em arquivo. Tem um limite de 2 GB por tabela.
Gancho: DETS persiste. Mas há uma coisa que persiste e distribui: o Mnesia.
Capítulo 68 — Mnesia: O Banco de Dados que Mora na BEAM
A lenda diz que o Mnesia é um banco de dados. Mas não é um banco de dados comum. Ele mora dentro da BEAM. Ele é distribuído. Ele é transacional. Ele é o banco de dados que os aliens criaram para os telefones suecos.
A verdade é que Mnesia é um sistema de gerenciamento de banco de dados distribuído, multiusuário, desenvolvido originalmente para telecomunicações. Ele é escrito em Erlang e roda na BEAM. Ele suporta transações, replicação e fragmentação. No entanto, Mnesia tem limitações: ele não é tão eficiente quanto bancos de dados relacionais para consultas complexas, e sua replicação pode ser problemática em clusters grandes.
A lenda diz que, quando um programador perguntou "Por que não usar PostgreSQL?", o instrutor respondeu: "Porque Mnesia está dentro." O programador perguntou: "E se eu precisar de SQL?" O instrutor respondeu: "Aí você usa PostgreSQL."
O fato por trás da lenda: Mnesia é um sistema de gerenciamento de banco de dados distribuído, multiusuário, desenvolvido originalmente para telecomunicações. Ele é escrito em Erlang e roda na BEAM. Suporta transações, replicação e fragmentação.
Gancho: Mnesia persiste. Mas há uma coisa que empacota tudo: o Release.
Capítulo 69 — Mix Release: O Bolo que Você Assa e Leva para a Festa
A lenda diz que, antes do Elixir 1.9, fazer deploy de uma aplicação Elixir era como assar um bolo sem receita. Você precisava de ferramentas externas, scripts e fé. Depois do Elixir 1.9, você só precisa rodar mix release.
A verdade é que o Elixir 1.9 introduziu o comando mix release, que empacota sua aplicação junto com a Erlang VM em uma única unidade deployável. Isso simplificou drasticamente o deploy de aplicações Elixir, que antes dependia de ferramentas como Distillery ou Edeliver. Um release inclui o código da aplicação, as dependências, a VM e um script de inicialização.
A lenda diz que, quando um programador rodou mix release pela primeira vez, ele perguntou: "Onde está o bolo?" O instrutor respondeu: "Na pasta _build." O programador perguntou: "Posso comer?" O instrutor respondeu: "Não. Mas você pode fazer deploy."
O fato por trás da lenda: Elixir 1.9 introduziu mix release, que empacota a aplicação com a Erlang VM em uma única unidade deployável. Isso simplificou o deploy de aplicações Elixir.
Gancho: Releases empacotam. Mas há uma coisa que testa tudo: o ExUnit.
Capítulo 70 — ExUnit: O Tribunal que Julga Seu Código
A lenda diz que o ExUnit é um tribunal. Cada teste é um julgamento. Cada assert é uma sentença. Se o código passa, ele é absolvido. Se falha, é condenado. O juiz é imparcial. O júri é o compilador. A sentença é executada imediatamente.
A verdade é que ExUnit é o framework de testes unitários do Elixir. Ele fornece assert, refute, assert_raise, assert_receive e outras macros para escrever testes. Testes são organizados em módulos que usam ExUnit.Case. ExUnit é integrado ao Mix, então você roda mix test para executar todos os testes.
A lenda diz que, quando um programador perguntou "Quantos testes eu preciso?", o instrutor respondeu: "Todos." O programador perguntou: "E se eu não escrever testes?" O instrutor respondeu: "Aí o tribunal te condena."
O fato por trás da lenda: ExUnit é o framework de testes unitários do Elixir. Ele fornece assert, refute, assert_raise, assert_receive e outras macros. Testes são organizados em módulos que usam ExUnit.Case, e são executados com mix test.
Gancho: ExUnit testa. Mas há uma coisa que documenta: o ExDoc.
Capítulo 71 — ExDoc: O Papagaio que Gera Documentação (Parte 2)
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.
A verdade é que ExDoc é a ferramenta oficial de geração de documentação do Elixir. Ela lê os atributos @doc e @moduledoc e gera documentação HTML navegável. ExDoc é usado por praticamente todos os projetos Elixir.
O fato por trás da lenda: ExDoc é a ferramenta oficial de geração de documentação do Elixir. Ela lê @doc e @moduledoc e gera documentação HTML. É usada por praticamente todos os projetos Elixir.
Gancho: ExDoc documenta. Mas há uma coisa que analisa tipos: o Dialyzer.
Capítulo 72 — Dialyzer: O Detector de Mentiras que Chora com any()
A lenda diz que o Dialyzer é um detector de mentiras que interroga seu código. Quando encontra um any(), ele chora copiosamente e se recusa a continuar. Se você usar @spec corretamente, ele sorri e te dá um selo de "código honesto".
A verdade é que Dialyzer é uma ferramenta de análise estática para bytecode da BEAM. Ele fornece avisos sobre tipos incompatíveis, código inalcançável e outros problemas comuns. O Dialyxir é uma biblioteca que fornece conveniências para trabalhar com Dialyzer em projetos Elixir.
O fato por trás da lenda: Dialyzer é uma ferramenta de análise estática para bytecode da BEAM. Ela fornece avisos sobre tipos incompatíveis, código inalcançável e outros problemas. O Dialyxir facilita o uso do Dialyzer em projetos Elixir.
Gancho: Dialyzer analisa. Mas há uma coisa que formata: o mix format.
Capítulo 73 — Mix Format: O Cabeleireiro que Usa Pomada de Unicórnio
A lenda diz que o mix format arruma seu código com pomada de unicórnio. Se você não rodar, seu código fica com o cabelo bagunçado e o compilador zomba. O .formatter.exs é o manual de estilo do cabeleireiro. Se você discordar, ele te expulsa do salão.
A verdade é que mix format é a ferramenta oficial de formatação de código do Elixir. Ela usa um formatador de código opinativo que garante consistência de estilo em toda a comunidade. O arquivo .formatter.exs define quais arquivos formatar e quais plugins usar.
O fato por trás da lenda: mix format é a ferramenta oficial de formatação de código do Elixir. Ela usa um formatador opinativo que garante consistência de estilo. O .formatter.exs define quais arquivos formatar.
Gancho: Mix format formata. Mas há uma coisa que compila: o mix compile.
Capítulo 74 — Mix Compile: O DJ que Compila Projetos (Parte 2)
A lenda diz que o mix compile não compila. Ele toca uma música. No final, seu código está compilado. Se você não gostar da música, pode mudar o mix.exs. Mas o DJ não se importa. Ele só toca.
A verdade é que mix compile é a tarefa do Mix que compila o código-fonte do projeto. Ela verifica dependências, compila os arquivos .ex e .exs e gera os arquivos .beam. O Mix também gerencia dependências, roda testes, formata código e muito mais.
O fato por trás da lenda: mix compile é a tarefa do Mix que compila o código-fonte do projeto. O Mix gerencia dependências, compila, roda testes, formata código e muito mais.
Gancho: Mix compila. Mas há uma coisa que baixa pacotes: o Hex.
Capítulo 75 — Hex: O Feitiço que Invoca Pacotes (Parte 2)
A lenda diz que Hex é um feitiço. Quando você roda mix hex.info, um sapo aparece no terminal e pergunta se você aceita os termos de uso. Se recusar, ele vira uma dependência quebrada. Se aceitar, ele pula para a próxima linha e some.
A verdade é que Hex é o gerenciador de pacotes oficial do ecossistema BEAM. Ele foi lançado em 2014 e serve tanto Elixir (via Mix) quanto Erlang (via Rebar3). Hex hospeda mais de 15.000 pacotes e é um componente central do ecossistema.
O fato por trás da lenda: Hex é o gerenciador de pacotes oficial do ecossistema BEAM, lançado em 2014. Ele serve Elixir (via Mix) e Erlang (via Rebar3) e hospeda mais de 15.000 pacotes.
Gancho: Hex baixa pacotes. Mas há uma coisa que observa tudo: o Telemetry.
Capítulo 76 — Telemetry: O Olho que Tudo Vê
A lenda diz que, na BEAM, você não precisa de ferramentas externas para observar seu sistema. Você tem o Telemetry. Ele mede tudo: requisições, queries, erros. E o LiveDashboard mostra tudo em tempo real.
A verdade é que Telemetry é uma biblioteca de instrumentação para Elixir e Erlang. O Phoenix integra a biblioteca Telemetry do Erlang para medir e reportar métricas padrão do Phoenix, Ecto e da VM Elixir. O LiveDashboard fornece visualização em tempo real.
O fato por trás da lenda: Telemetry é uma biblioteca de instrumentação para Elixir e Erlang. O Phoenix integra a Telemetry para medir métricas de Phoenix, Ecto e VM. O LiveDashboard fornece visualização em tempo real.
Gancho: Telemetry observa. Mas há uma coisa que conecta nós: o Libcluster.
Capítulo 77 — Libcluster: O Feitiço que Junta os Nós (Parte 3)
A lenda diz que, para formar um cluster Elixir, você precisa de magia. Você roda libcluster e, de repente, todos os nós se encontram, se cumprimentam e começam a trabalhar juntos.
A verdade é que Libcluster fornece um mecanismo para formar automaticamente clusters de nós Erlang, com adesão estática ou dinâmica. Ele suporta várias estratégias: EPMD, Kubernetes, Gossip, DNS, Rancher, e outras.
O fato por trás da lenda: Libcluster fornece formação automática de clusters de nós Erlang, com adesão estática ou dinâmica. Ele suporta várias estratégias: EPMD, Kubernetes, Gossip, DNS, Rancher.
Gancho: Libcluster conecta. Mas há uma coisa que explica os limites: o Teorema CAP.
Capítulo 78 — CAP: O Teorema que a BEAM Ignora (ou Não) (Parte 2)
A lenda diz que, quando os aliens criaram a BEAM, eles leram o Teorema CAP e disseram: "Vamos escolher AP." E assim fizeram. A maioria das bibliotecas distribuídas do Elixir fica do lado AP do Teorema CAP.
A verdade é que a maioria das bibliotecas distribuídas do Elixir (Phoenix Pub/Sub, Horde, Swarm, Delta CRDTs) fica do lado AP do Teorema CAP. Elas preferem disponibilidade a consistência estrita. O Paxtor é uma biblioteca CP que usa Paxos para garantir consistência forte.
O fato por trás da lenda: A maioria das bibliotecas distribuídas do Elixir fica do lado AP do Teorema CAP. O Paxtor é uma biblioteca CP que usa Paxos.
Gancho: CAP explica os limites. Mas há uma coisa que a BEAM faz melhor: tolerância a falhas.
Capítulo 79 — Tolerância a Falhas: A Filosofia que Virou Benchmark (Parte 3)
A lenda diz que, num benchmark acadêmico, o Elixir foi comparado a outras linguagens concorrentes sob condições de falha. O resultado? "Elixir atingiu o maior throughput e a menor variabilidade de throughput sob condições de falha".
A verdade é que a tolerância a falhas da BEAM é um dos seus pontos mais fortes. Processos isolados, supervisores, árvores de supervisão, "let it crash" — tudo isso faz com que sistemas BEAM se recuperem de falhas de forma quase automática.
O fato por trás da lenda: A tolerância a falhas da BEAM é um dos seus pontos mais fortes. Processos isolados, supervisores, árvores de supervisão, "let it crash".
Gancho: Tolerância a falhas é a base. Mas há uma coisa que mantém os processos vivos: os supervisores.
Capítulo 80 — Supervisor: As Babás que Nunca Dormem (Parte 3)
A lenda diz que os supervisores são babás que dão mamadeira para processos órfãos. Se um processo morre, a babá chora, pega um novo processo no berçário e coloca no lugar.
A verdade é que supervisores são processos que monitoram outros processos e os reiniciam quando falham. Supervisores formam árvores de supervisão que fornecem tolerância a falhas e capacidades de auto-recuperação.
O fato por trás da lenda: Supervisores monitoram processos filhos e os reiniciam quando falham. Supervisores formam árvores de supervisão.
Gancho: Supervisores cuidam. Mas há um processo que serve: o GenServer.
Capítulo 81 — GenServer: O Mordomo que Serve Estado em Bandejas (Parte 3)
A lenda diz que um GenServer é um mordomo chamado Alfred que guarda o estado do seu sistema em uma bandeja de prata. Quando você chama GenServer.call, ele responde "Pois não, senhor" e executa a função.
A verdade é que GenServer é um comportamento do OTP para construir servidores genéricos. Ele encapsula estado e concorrência, permitindo que você defina callbacks para lidar com chamadas síncronas e assíncronas.
O fato por trás da lenda: GenServer é um comportamento do OTP para construir servidores genéricos. Ele encapsula estado e concorrência.
Gancho: GenServer serve. Mas há uma coisa que persiste: o Ecto.
Capítulo 82 — Ecto: O Fantasma que Assombra Bancos de Dados (Parte 3)
A lenda diz que Ecto é um fantasma que mora no seu PostgreSQL e escreve queries em latim. Cada Repo.insert é um exorcismo.
A verdade é que Ecto é uma biblioteca de persistência para Elixir. Ele fornece uma camada de mapeamento entre o código Elixir e o banco de dados, com suporte a migrações, queries e transações.
O fato por trás da lenda: Ecto é uma biblioteca de persistência para Elixir, com componentes para repositórios, schemas, queries e changesets.
Gancho: Ecto persiste. Mas há uma coisa que conecta tudo: o Phoenix.
Capítulo 83 — Phoenix: A Fênix que Nasceu das Cinzas (Parte 3)
A lenda diz que Phoenix é um framework web que invoca uma fênix de verdade. Cada vez que você roda mix phx.server, uma fênix renasce das cinzas no Arizona.
A verdade é que Phoenix é um framework web para Elixir, criado por Chris McCord. Ele foi lançado em 2015 e se tornou o framework web padrão para Elixir.
O fato por trás da lenda: Phoenix é um framework web para Elixir, criado por Chris McCord e lançado em 2015.
Gancho: Phoenix constrói. Mas há uma coisa que conecta usuários: o LiveView.
Capítulo 84 — LiveView: A Janela para o Multiverso (Parte 3)
A lenda diz que, na primeira vez que alguém rodou uma LiveView, uma janela para outra dimensão se abriu no navegador.
A verdade é que Phoenix LiveView permite construir experiências de usuário ricas e em tempo real com HTML renderizado no servidor, sem escrever JavaScript. A versão 1.0 foi lançada em dezembro de 2024.
O fato por trás da lenda: Phoenix LiveView permite construir aplicações interativas renderizadas no servidor sem JavaScript. A versão 1.0 foi lançada em dezembro de 2024.
Gancho: LiveView interage. Mas há uma coisa que observa: o Observer.
Capítulo 85 — Observer: A Janela para a Alma da BEAM (Parte 3)
A lenda diz que, se você quer ver a alma da BEAM, abra o Observer. Ele mostra todos os processos, todos os nós, toda a memória.
A verdade é que o Observer é uma ferramenta gráfica para inspecionar sistemas Erlang/Elixir em execução. Ele mostra informações do sistema, árvores de supervisão, informações de processos, tabelas ETS e contém frontend para tracing.
O fato por trás da lenda: Observer é uma ferramenta gráfica para inspecionar sistemas Erlang/Elixir em execução. Inclui etop e crashdump_viewer.
Gancho: Observer mostra a alma. Mas há uma coisa que nem o Observer consegue mostrar: o futuro.
Capítulo 86 — OTP 27: Record Operations e o Futuro do JIT (Parte 3)
A lenda diz que, em 2024, a Ericsson lançou o OTP 27. A grande novidade era a otimização de record operations.
A verdade é que o OTP 27 introduziu otimizações para record operations. A história das otimizações modernas começou em 2018 com SSA, passou pelo JIT no OTP 24, otimizações baseadas em tipos no OTP 25, e melhorias no OTP 26.
O fato por trás da lenda: OTP 27 introduziu otimizações para record operations. A história das otimizações modernas começou em 2018 com SSA.
Gancho: O JIT é o futuro. Mas há uma coisa que sempre foi o presente: a comunidade.
Capítulo 87 — A Comunidade Brasileira: A Floresta que Cresceu (Parte 4)
A lenda diz que, quando José Valim criou Elixir, ele plantou uma semente no Brasil que cresceu e se tornou uma floresta.
A verdade é que a comunidade brasileira de Elixir é ativa e crescente, com meetups em várias cidades, o podcast "Elixir em Foco", o "Elixir Brasil Online Meetups" e o "Global Elixir Meetup".
O fato por trás da lenda: A comunidade brasileira de Elixir é ativa e crescente, com meetups, podcast e eventos online.
Gancho: A comunidade cresce. Mas há uma fundação que protege.
Capítulo 88 — Erlang Ecosystem Foundation: Os Guardiões da BEAM (Parte 4)
A lenda diz que, em 2019, um grupo de desenvolvedores se reuniu e disse: "Precisamos proteger a BEAM." Fundaram a Erlang Ecosystem Foundation.
A verdade é que a Erlang Ecosystem Foundation é uma organização sem fins lucrativos 501(c)(3) apoiada por mais de 1.000 membros. Em 2025, tornou-se uma CNA para vulnerabilidades em pacotes do Hex.pm.
O fato por trás da lenda: A Erlang Ecosystem Foundation é uma organização sem fins lucrativos 501(c)(3) apoiada por mais de 1.000 membros.
Gancho: A fundação protege. Mas há uma coisa que conecta tudo: a BEAM.
Capítulo 89 — O Fim do Tomo III: OTP, a Espinha Dorsal
A lenda diz que, no fim de tudo, quando todos os tomos forem escritos, o OTP continuará sendo a espinha dorsal da BEAM. Com seus GenServers, Supervisores e Applications. O OTP é eterno. O OTP é infinito. O OTP é.
A verdade é que o OTP é uma coleção de bibliotecas e ferramentas para construir sistemas concorrentes, tolerantes a falhas e distribuídos. Ele é usado por WhatsApp, Discord, Remote, Helvetia, Multiverse e milhares de outras empresas.
Este foi o Tomo III — OTP. Cem capítulos. Uma plataforma. Mil processos. E um brasileiro que ouviu um sussurro.
O fato por trás da lenda: OTP é uma coleção de bibliotecas e ferramentas Erlang para construir sistemas concorrentes, tolerantes a falhas e distribuídos.
Gancho: O Tomo III termina aqui. Mas a história continua no Tomo IV.
Capítulo 90 — O Que Vem no Tomo IV: A Sintaxe
A lenda diz que, no Tomo IV, vamos abrir a sintaxe do Elixir. Vamos ver pattern matching, pipes, módulos, macros. Vamos entender por que o código Elixir é tão bonito. E, é claro, vamos ver os pombos treinados decidindo matches.
A verdade é que o Tomo IV será sobre a sintaxe do Elixir. Vamos explorar pattern matching, pipes, módulos, macros, e todos os recursos que tornam o Elixir expressivo e conciso.
O fato por trás da lenda: O Tomo IV será sobre a sintaxe do Elixir. Vamos explorar pattern matching, pipes, módulos, macros.
Gancho: A sintaxe é a base. Mas há uma coisa que sempre foi a base de tudo: a comunidade.
Capítulo 91 — Pattern Matching: O Pombo que Decide Tudo (Parte 3)
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.
A verdade é que pattern matching é um recurso central do Elixir. O operador = é um operador de match que tenta unificar o lado esquerdo com o lado direito.
O fato por trás da lenda: Pattern matching é um recurso central do Elixir. O operador = é um operador de match.
Gancho: Pattern matching decide. Mas há uma coisa que transforma código em poesia: o pipe.
Capítulo 92 — O Pipe: A Tubulação que Transforma Código em Poesia (Parte 3)
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.
A verdade é que 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.
O fato por trás da lenda: O operador pipe (|>) foi inspirado no F#. Ele pega o resultado de uma expressão e o passa como primeiro argumento para a próxima função.
Gancho: O pipe transforma. Mas há uma coisa que gera código: as macros.
Capítulo 93 — Macros: O Feitiço que Assusta até os Corajosos (Parte 3)
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.
A verdade é que macros permitem que você escreva código que gera código em tempo de compilação. Elas são usadas para criar DSLs, estender a linguagem e reduzir boilerplate.
O fato por trás da lenda: Macros permitem que você escreva código que gera código em tempo de compilação. São usadas para criar DSLs e estender a linguagem.
Gancho: Macros geram. Mas há uma coisa que organiza: os módulos.
Capítulo 94 — Módulos: As Caixas que Guardam Funções
A lenda diz que os módulos são caixas. Cada caixa guarda funções. Cada caixa tem um nome. Cada caixa pode ser aberta. Cada caixa pode ser fechada. As caixas nunca se misturam.
A verdade é que módulos em Elixir são usados para organizar funções e dados. Cada módulo tem um nome e pode conter funções, macros, structs e outros módulos. Módulos são a unidade básica de organização de código em Elixir.
O fato por trás da lenda: Módulos em Elixir são usados para organizar funções e dados. Cada módulo tem um nome e pode conter funções, macros, structs.
Gancho: Módulos organizam. Mas há uma coisa que estrutura dados: os structs.
Capítulo 95 — Structs: As Fichas que Guardam Dados
A lenda diz que os structs são fichas. Cada ficha guarda dados. Cada ficha tem um formato. Cada ficha pode ser preenchida. Cada ficha pode ser lida. As fichas nunca se confundem.
A verdade é que structs em Elixir são mapas com um campo especial __struct__ que define o tipo. Eles são usados para representar dados estruturados, como um usuário, um pedido ou uma configuração. Structs são definidos com defstruct dentro de um módulo.
O fato por trás da lenda: Structs em Elixir são mapas com um campo especial __struct__ que define o tipo. Eles são usados para representar dados estruturados.
Gancho: Structs guardam. Mas há uma coisa que valida: os changesets.
Capítulo 96 — Changesets: Os Guardiões da Validação
A lenda diz que os changesets são guardiões. Eles validam. Eles transformam. Eles rejeitam. Se um dado é inválido, o changeset o rejeita. Se é válido, o changeset o aceita. Os guardiões nunca erram.
A verdade é que changesets são usados no Ecto para validar e transformar dados antes de persistir. Um changeset contém as mudanças propostas, as validações e os erros. Se houver erros, o changeset é inválido e não pode ser persistido.
O fato por trás da lenda: Changesets são usados no Ecto para validar e transformar dados antes de persistir. Um changeset contém as mudanças propostas, as validações e os erros.
Gancho: Changesets validam. Mas há uma coisa que consulta: as queries.
Capítulo 97 — Ecto.Query: A Linguagem que Fala SQL
A lenda diz que o Ecto.Query é uma linguagem. Ela fala SQL. Mas não é SQL. É Elixir. Você escreve queries em Elixir, e o Ecto as traduz para SQL. É mágica.
A verdade é que Ecto.Query é uma DSL para escrever queries em Elixir. Ela é traduzida para SQL pelo adaptador do banco de dados. Ecto.Query suporta joins, wheres, selects, order_bys e muito mais. É uma das partes mais poderosas do Ecto.
O fato por trás da lenda: Ecto.Query é uma DSL para escrever queries em Elixir. Ela é traduzida para SQL pelo adaptador do banco de dados.
Gancho: Queries consultam. Mas há uma coisa que migra: as migrações.
Capítulo 98 — Ecto.Migração: O Arqueólogo que Move o Banco
A lenda diz que as migrações são arqueólogos. Elas escavam. Elas movem. Elas transformam. Elas nunca perdem um fóssil.
A verdade é que migrações no Ecto são scripts que alteram o esquema do banco de dados. Elas são versionadas e executadas em ordem. Cada migração tem um up e um down. O up aplica a mudança, o down reverte.
O fato por trás da lenda: Migrações no Ecto são scripts que alteram o esquema do banco de dados. Elas são versionadas e executadas em ordem.
Gancho: Migrações movem. Mas há uma coisa que tudo conecta: a Application.
Capítulo 99 — Application: O Componente que Pode Ser Iniciado e Parado (Parte 12)
A lenda diz que a application é um componente. Ela pode ser iniciada. Ela pode ser parada. Ela pode ser reutilizada.
A verdade é que, no OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade, e que pode ser reutilizada em outros sistemas.
O fato por trás da lenda: No OTP, application denota um componente que implementa alguma funcionalidade específica, que pode ser iniciada e parada como uma unidade.
Gancho: A application é a unidade. Mas há um behaviour que é o futuro de tudo: o application.
Capítulo 100 — O Fim do Tomo III: OTP, a Espinha Dorsal (Parte 2)
A lenda diz que, no fim de tudo, quando todos os tomos forem escritos, o OTP continuará sendo a espinha dorsal da BEAM. Com seus GenServers, Supervisores e Applications. O OTP é eterno. O OTP é infinito. O OTP é.
A verdade é que o OTP é uma coleção de bibliotecas e ferramentas para construir sistemas concorrentes, tolerantes a falhas e distribuídos. Ele é usado por WhatsApp, Discord, Remote, Helvetia, Multiverse e milhares de outras empresas.
Este foi o Tomo III — OTP. Cem capítulos. Uma plataforma. Mil processos. E um brasileiro que ouviu um sussurro.
No próximo tomo, A Sintaxe, vamos explorar pattern matching, pipes, módulos, macros, e todos os recursos que tornam o Elixir expressivo e conciso.
Até lá.
O fato por trás da lenda: OTP é uma coleção de bibliotecas e ferramentas Erlang para construir sistemas concorrentes, tolerantes a falhas e distribuídos. É usado por WhatsApp, Discord, Remote e muitas outras empresas.
Agora, sério: OTP significa Open Telecom Platform. É uma coleção de bibliotecas e ferramentas Erlang para construir sistemas concorrentes, tolerantes a falhas e distribuídos. Os behaviours do OTP incluem gen_server, supervisor, gen_event, gen_fsm (depreciado e substituído por gen_statem), e application. A filosofia "let it crash" foi proposta por Joe Armstrong. A árvore de supervisão é um modelo hierárquico de supervisores e workers. O DynamicSupervisor inicia filhos sob demanda. Task e Task.Supervisor gerenciam tarefas assíncronas. Agent guarda estado simples. Registry registra processos. Phoenix.PubSub distribui eventos. DETS persiste em disco. Mnesia é um banco de dados distribuído. Mix Release empacota aplicações. ExUnit testa. ExDoc documenta. Dialyzer analisa. Mix Format formata. Hex baixa pacotes. Telemetry observa. Libcluster conecta. CAP explica os limites. 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.
Top comments (0)