Dez anos de programação em Erlang

Entrei para a comunidade Erlang há cerca de 10 anos, no meio da primeira fase do hype. Fomos informados de que Erlang é o futuro da concorrência e da concorrência. Implementá-los nesse idioma é o mais fácil e rápido, e você ainda recebe distribuição gratuita. Naquela época, o futuro parecia inacreditável. A máquina virtual recebeu recentemente o suporte SMP , mas para realmente usar todos os processadores, era necessário executar várias máquinas virtuais no mesmo computador.

Eu quero refletir sobre a década passada. Neste artigo, falarei sobre as fases do hype em relação a Erlang, sobre a escada de idéias na linguagem e sobre seu possível impacto na distribuição da linguagem, sobre as mudanças pelas quais passei nesses 10 anos. Concluindo, compartilharei meus pensamentos sobre o que Erlang ainda tem que trazer para a comunidade de programadores como um todo.

Fase de campanha publicitária

O ciclo de hype consiste nas fases do ciclo de vida de um produto ou tecnologia. Este é um conceito de marketing, não científico, mas muitas vezes ajuda a descrever a essência do que está acontecendo. O que mais me interessa é a fase do hype , uma espécie de corrida do ouro que cobre a comunidade de programadores. Talvez você tenha se deparado com isso mais de uma vez, e todas essas fases estejam conectadas a algum aplicativo matador que todos correm para usar.

Os exemplos imediatamente vêm à mente são Ruby on Rails, Como criar um mecanismo de blog em 15 minutos (a frase “Veja tudo o que eu não faço!” Ainda é engraçado) ou Vá com o Kubernetes (eles trabalharam juntos antes disso, e houve um aumento direto). Isso inclui Elixir e Phoenix.

Durante a fase de campanha publicitária, há um incrível fluxo de recém-chegados que querem ver o motivo de toda essa confusão. Alguém permanece, a maioria sai. Você pode ficar por meses ou anos, em casos raros, encontra um lar por décadas. No entanto, a grande maioria é um fluxo constante de pessoas em série que saltam de tecnologia em tecnologia, procurando oportunidades para se beneficiarem do fato de serem as primeiras a usar uma estrutura, linguagem ou kit de ferramentas.

Então, na maioria das vezes, você precisa criar um "aplicativo matador" real, e as pessoas chegarão ao seu ecossistema. O aplicativo matador gera excitação. Se você escrever, eles virão até você. E se você puder manter uma pequena fração deles e mantê-los ativos, terá uma comunidade vibrante no futuro próximo. Isso lembra um pouco a idéia de chuva após um arado :

O Senhor dirige o arado ... Após essa adaptação maravilhosa, que é o único domínio do homem sobre a natureza, as nuvens derramam fortes chuvas ... [arado] é uma ferramenta que separa a civilização da barbárie, transforma o deserto em fazendas e jardins. ... Em suma, a chuva segue o arado.

A essência da teoria era que a habitação e a agricultura humanas têm um impacto irreversível no clima das regiões áridas e semi-áridas, tornando essas regiões mais úmidas. Essa teoria se espalhou na década de 1870 como justificativa para o assentamento das Grandes Planícies, uma região anteriormente conhecida como o Grande Deserto Americano. Naqueles anos, essa teoria foi usada para justificar a expansão das culturas de trigo nas terras marginais do sul da Austrália.

Se conseguirmos lançar um projeto grande, os desenvolvedores aparecerão e ele se tornará auto-suficiente. Eu acho que essa ideia é claramente errada, principalmente porque Erlang teve dezenas de aplicativos matadores durante a maior fase de hype, mas a comunidade ainda é pequena. Aqui estão exemplos desses aplicativos:

• ejabberd (2002, primeiro lançamento estável em 2005): foi um dos servidores de bate-papo mais, se não o mais escalável. O Ejabberd alcançou grande sucesso e, até certo ponto, ainda é relevante. Hoje, no StackOverflow, ainda existem dúvidas sobre os módulos para este servidor. Por volta de 2011, ele entrou no MongooseIM , e as duas soluções ainda são suportadas.
  
• CouchDB (2005): um dos bancos de dados mais populares escritos em Erlang, que foi baseado no teorema da CAP . Refere-se ao tempo do surgimento de repositórios multimaster. Embora o MongoDB ocupasse a maior parte do mercado, o CouchDB tem sucessores espirituais entre os mecanismos de armazenamento como o BarrelDB , que ainda é suportado.
  
• RabbitMQ (2007): um servidor de enfileiramento de mensagens que esmagou a maior parte do mercado AMQP. Ele se desenvolve e geralmente compete com o Kafka no que diz respeito ao streaming de cargas, embora esses produtos tenham recursos e aplicativos diferentes.
  
• Chat no Facebook (2008): A versão inicial do Facebook Chat foi escrita em Erlang. Por várias razões internas (estabilidade, um grande número de programadores em C ++ e várias soluções estabelecidas), foi posteriormente reescrito em C ++.
  
• WhatsApp (2009, comprado em 2014): quando o Facebook se livrou do sistema de bate-papo Erlang, eles compraram o WhatsApp, que exigia apenas 50 engenheiros para o suporte de 900 milhões de usuários . Ele vive até hoje e, além do mais, a equipe do WhatsApp fortaleceu ainda mais os laços com as comunidades Erlang e Elixir.
  
• Riak (2009): Um dos melhores exemplos de demonstração de poder no mundo dos sistemas distribuídos. Riak era um armazenamento distribuído confiável do tipo de valor-chave. Este é um produto Basho que ainda funciona em sistemas de saúde e em outras partes críticas da infraestrutura. Mais tarde, Basho faliu (em grande parte devido a violações de deveres fiduciários , que "a toda velocidade levaram a empresa ao colapso" ). Então o Bet365 comprou todos os seus IPs, os abriu generosamente e, desde então, o banco de dados vive no mundo do código aberto, embora hoje esteja passando por momentos difíceis.
  

Muitos desses produtos foram lançados durante a primeira edição do livro Programming Erlang, de Joe Armstrong. Como resultado, surgiu uma explosão da popularidade do idioma, e Erlang ganhou muitos admiradores. Um impacto significativo foi mesmo o fato de o Hacker News ter forçado todas as discussões sobre as entranhas de Erlang . No entanto, poucos permaneceram fiéis a esse idioma.

Agora, acredito que aplicativos matadores são criados por pessoas que formam a fase inicial do hype, e não vice-versa. Sempre há uma pequena parte das pessoas que procuram tecnologias interessantes antes dos outros, decidem se gostam delas, depois criam algo e, se você obtém um aplicativo matador, isso estimula o desenvolvimento de uma fase de hype ainda mais poderosa. As pessoas se envolverão no culto à carga e projetos bem-sucedidos produzirão imitadores. Além disso, a situação padrão é a fase da “invenção da roda”, quando todo mundo gasta seu tempo reinventando coisas existentes, e há uma onda de mensagens sobre a “implementação do X, mas na linguagem Y”.

No entanto, apenas criar um aplicativo matador não é suficiente. Curiosamente, todos esses produtos, como RabbitMQ e Ejabberd, apesar de sua popularidade, têm uma comunidade de usuários muito maior que a comunidade de desenvolvedores. Milhares e milhares de empresas que usam esses produtos não necessariamente contribuem significativamente para a comunidade Erlang.

Isso se deve em parte ao fato de a maioria dos aplicativos Erlang mais sofisticados serem usados ​​em infra-estruturas especializadas. Você criou um componente altamente confiável na forma de uma caixa preta que todos usam e, se funcionar bem, ninguém procurará dentro. Várias dezenas de desenvolvedores forneceram a base para milhares de outros produtos e serviços. A infraestrutura especializada, por definição, não precisa de um grande número de pessoas para garantir seu impacto generalizado. Ele sempre tem poucos desenvolvedores e uma pequena comunidade em comparação com tecnologias mais próximas do produto final, por exemplo, estruturas da web ou infraestruturas ainda mais generalizadas usadas em pequenos projetos de implantação adequados para qualquer empresa.

Mas mesmo com tudo isso, é óbvio que Erlang perdeu muitas pessoas que passaram por isso durante a fase de hype.

Escadaria de idéias

Não vou reclamar sobre o que poderia ou deveria ter sido feito. Em vez disso, quero falar sobre os padrões populares de aprendizado que encontrei na comunidade Erlang ao longo dos anos de ensino e programação desse idioma. Hoje observo os mesmos padrões na comunidade Elixir, e isso pode indicar um futuro semelhante para ele.

Eu tenho uma teoria de que um tópico técnico como uma linguagem de programação (e seu ecossistema) possui vários níveis de complexidade nos quais diferentes conceitos estão localizados. Eu usei essa teoria no projeto Learn You Some Erlang . É apresentado no diagrama, que chamei de círculos dos Nove Earl .

Claro, essa é uma ideia irônica, não acho que o estudo de uma tecnologia seja um sofrimento sem fim (pelo menos não deveria ser). Eu apenas gostei do trocadilho. Simplificando, sempre existe algum tipo de caminho ou sequência “principal” daqueles que você aprende quando estuda tecnologia - essa é a “escada de idéias”, e quanto mais alto o conceito estiver localizado nessa escada, mais valioso e mais difícil é alcançar, menos pessoas conhece ela.

Como seria a escada de idéias em Erlang:

1. Programação funcional.
   
2. Processos isolados e competitividade.
   
3. Competitividade confiável (links, monitores, tempos limite).
   
4. Princípios OTP e outras abstrações do sistema.
   
5. Como estruturar sistemas de acordo com os princípios da OTP.
   
6. Como coletar liberações e trabalhar com elas (implantação).
   
7. Como evitar uma falha no sistema e trabalhar com ele.
   

Se você conhece Erlang e compra um livro para iniciantes, provavelmente passa os primeiros dias no primeiro passo da escada: familiarização com programação funcional, imutabilidade (imutabilidade), recursão e outros conceitos semelhantes. Mais cedo ou mais tarde, você chegará à competitividade e ao paralelismo, processos e mensagens. Imediatamente após eles, você começará a aprender sobre links e monitores, lidar com falhas e o que Erlang faz do que é. Durante a grande fase de hype, os segundo e terceiro passos continham oportunidades que para a maioria dos observadores pareciam simplesmente inacreditáveis. Se você precisar aprender algo que usará em todos os projetos futuros, poderá escolher um desses recursos do Erlang.

Você pode avançar para outras etapas mais tarde, mas apenas se aderir ao programa de treinamento passo a passo. Em particular, o OTP (quarta etapa) pode ser descrito como "do que se trata". A competitividade e a programação funcional são boas, mas a estrutura geral apresentada com o OTP era realmente única e precisava ser usada. Com o tempo, muitos vão trabalhar com ele, acham que podem criar abstrações interessantes, mas não gostam da abordagem de estruturação.

De fato, para criar aplicativos como o Ejabberd, bastava superar o quarto passo. Naqueles dias, o ecossistema se assemelhava ao Oeste Selvagem, e o conhecimento da OTP era de propriedade de especialistas que trabalhavam na Ericsson, bem como do autodidata mais motivado. A maioria nunca chegou ao quinto estágio, a menos que enviasse algo para a produção e depois encontrasse problemas ou se não procurasse uma solução melhor. A conquista da sexta etapa foi rara até 2015-2016 e, em seguida, apareceu o Relx , o que simplificou a montagem de lançamentos e seu desenvolvimento. Quase ninguém alcançou a sétima etapa, e muitas pessoas pensam que não devem executar uma atualização quente do nó Erlang e, idealmente, você nunca precisará usar o SSH para depuração na produção.

Na prática, nem todo mundo sobe a escada de idéias na mesma ordem; seus passos em alguns livros são invertidos (por exemplo, em Erlang e OTP em Ação ). Não há nada de errado nisso, a escada foi inventada apenas como ilustração.

O tamanho das comunidades está mudando em ondas. Durante as fases do hype, o tamanho por algum tempo pode aumentar em dezenas ou centenas de vezes, e todas essas pessoas ficarão curiosas e vão embora. A maioria dos participantes se senta no primeiro degrau da escada e raramente o deixa para trás. Alguns chegam ao segundo estágio, menos ainda ao terceiro, e assim por diante, até chegar a um círculo estreito de especialistas no mais alto nível.

Eu acho que subir os três primeiros degraus de Erlang foi fácil. Para subir para o quarto, foi necessário se desenvolver por vários anos e, de fato, sentir a necessidade de mais estudos. No quinto passo já é muito difícil. O kit de ferramentas e o ecossistema de Erlang eram pobres. Os membros da comunidade suportaram esse ambiente árido e foram indiferentes à situação difícil dos recém-chegados. Para tornar o artigo mais curto (bem, longo, mas não absurdamente longo), veja minha palestra sobre o ecossistema de idiomas na Erlang User Conference:


Se você escreve no Elixir, provavelmente vê em que degrau da escada em que está parado e já pode imaginar em que proporções a comunidade está distribuída por ela. Muitos participantes são fluentes apenas em Phoenix, mas raramente se levantam acima do quarto passo, e muitos ficam presos no terceiro e mais baixo. E muitas vezes isso é suficiente. Não culpo, mas apenas compartilho a observação. Como qualquer pessoa que tenha subido muitos degraus (e provavelmente há muitos outros passos à minha frente, como “consertar uma máquina virtual” ou outra coisa), vejo que essas pessoas não sabem muito. Mas, honestamente, todas essas informações podem ser inúteis para eles. E isso é bom.

O que quero dizer: acredito que nós, como comunidade, provavelmente estamos vendo cadelas debaixo de nós, tornando muito difícil dominar a escada de idéias acima do nível básico. Alguns tópicos precisam ser estudados lentamente e, em alguns, os cegos lideram os cegos, porque Erlang é tão pequeno que temos poucas pessoas que podem compartilhar toda a experiência necessária. Hoje é mais simples e, se você não veio a Erlang na fase de hype, provavelmente receberá ajuda, pois muito menos pessoas estão pedindo por isso ao mesmo tempo.

Gostaria de pensar que, se a segunda fase do hype começar no mundo de Erlang amanhã, poderemos aceitar os recém-chegados melhor do que durante a grande onda, quando eu vim. E espero que essa experiência, juntamente com uma colaboração mais estreita entre as comunidades Erlang e Elixir, duplique nossas chances de expandir com sucesso o uso desses idiomas.

O que mudou

Erlang não nada no frasco, esperando que ele seja puxado para a luz. Está em constante evolução. Isso se deve em parte à concorrência e sugestões da comunidade Elixir, que, felizmente, espera muito mais de suas ferramentas do que o que os usuários do Erlang estão acostumados. E em parte o desenvolvimento é determinado pelas necessidades urgentes da indústria e pelos desejos da comunidade acadêmica.

Eu acho que alguém ficará satisfeito com essas mudanças que ocorreram desde 2009 ou mesmo antes:

• O suporte multinúcleo agora funciona bem. Anteriormente, se houvesse mais de 2 a 4 núcleos, o sistema repousava em todos os tipos de gargalos que não estavam sujeitos ao desenvolvedor do aplicativo. Então tornou-se possível usar 12-16 núcleos. Hoje, eu nem sei qual é o limite superior, mas escrevi e gerenciei pilhas que funcionavam em mais de 32 núcleos sem problemas.
  
• Rastreamentos de pilha agora têm números de linha. É quase impensável voltar ao passado, antes que os números aparecessem. Naqueles anos, “escrever pequenas funções auto-documentadas” não era uma questão de arquitetura, mas de sobrevivência. Agora você pode depurar programas Erlang sem habilidades de depuração sobrenatural, apesar de nunca prejudicarem.
  
• Atualmente, a qualidade do suporte a Unicode é aceitável. O módulo de strings contém os algoritmos mais importantes e o módulo unicode faz um excelente trabalho com a maioria dos tipos de transformações e normalizações. Existem abordagens típicas para trabalhar com pontos de código, UTF-8, UTF-16 e UTF-32. O suporte local ainda deixa muito a desejar, mas todo o resto está operacional. Módulos como re (um módulo para trabalhar com expressões regulares) e todas as funções de alto nível para trabalhar com arquivos também não apresentam problemas ao trabalhar com Unicode.
  
• Mapas (implementados como HAMT ) com sintaxe explícita de correspondência de padrões são suportados . Com a ajuda da análise do tipo Dialyzer, é aplicada a eles, o que permite que sejam usados ​​nos casos em que anteriormente o uso de registros exigia muito esforço.
  
• As máquinas virtuais agora usam excelentes mecanismos para trabalhar com o tempo , lidam com uma mudança na escala de tempo, com diferentes tipos de relógios e muito mais. No entanto, trabalhar com fusos horários e formatar o horário é melhor com a ajuda de bibliotecas desenvolvidas pela comunidade.
  
• Ferramentas de alto desempenho, como atômica , contadores e termos persistentes foram adicionadas para ajudar a melhorar os vários mecanismos subjacentes às ferramentas de vigilância e bibliotecas básicas de baixo nível.
  
• Todo o processamento de sinais se tornou assíncrono , incluindo o trabalho com portas , o que nos salvou de muitos gargalos.
  
• O compilador foi reescrito e ainda está sendo reescrito para aprimorar a análise e o desempenho de alto nível usando o SSA.
  
• Havia um tipo especial de agendadores para uso no NIF - agendadores sujos, que simplificavam a integração com o código escrito em c ou até ferrugem, suportando processos intensivos de CPU e E / S. Portanto, embora a linguagem em si não tenha se tornado muito mais rápida (embora haja progresso), ficou muito mais fácil conectar bibliotecas de alto desempenho sem afetar indevidamente a estabilidade da máquina virtual.
  
• Várias melhorias foram feitas no mecanismo para alocar e gerenciar memória.
  
• A análise do programa tornou-se mais precisa e rápida, graças ao rastreamento e contabilidade mais rápidos e flexíveis para microestados .
  
• O comportamento OTP mais flexível do gen_statem permitiu a implementação de máquinas de estados finitos que podem processar dados de entrada seletivamente.
  
• Estrutura de log nova e aprimorada com suporte interno para logs estruturados.
  
• O módulo de criptografia é reescrito e usa NIF em vez dos drivers mais complexos (e geralmente atualizados mais lentamente).
  
• O driver do arquivo foi totalmente reescrito usando o NIF, o que melhorou bastante o desempenho.
  
• Para obter o mesmo desempenho, eles continuam a reescrever os drivers de rede usando o NIF.
  
• Redesenhado completamente o uso de SSL para processamento TLS. Quando trabalhei na Heroku, tentamos tornar o produto comparável às soluções C ++ em termos de atraso (talvez 5% pior) e ultrapassar significativamente a previsibilidade (10 a 30 vezes menos que 99 percentis).
  
• Desempenho do ETS significativamente aprimorado.
  
• Escrevi um guia para gerenciar e depurar sistemas de produção em máquinas virtuais Erlang.
  
• Uma ferramenta de construção completamente nova ( rebar3 ), integrada ao gerenciador de pacotes unificado para o ecossistema Erlang.
  
• , . Elixir, Efene, LFE, Luerl, Clojerl Gleam Alpaca.
  
• Erlang.
  

, . , OTP Ericsson 13-16 ( 22!), Erlang . , Ericsson. Erlang Elixir, Erlang VM , Erlang Ecosystem Foundation , , , (observability — ), , ..

, , , , , , , , , Erlang . .

Erlang

, , 2007-2009, , . Erlang , . , , BEAM Conf. (Property-Based Testing), Erlang Elixir . , . , .

? , , , . , Elixir. , , , . , . , . . , . Erlang, , .

, Erlang . , , Erlang-, Erlang-: , , . , .

Erlang -, Elixir-.

, , Erlang . , . Erlang , . , .

, . ? ? , - ? , , ? ? , ? « - »?

, , « ». , Erlang . , . junior senior-, , , , .

, 15 ( , ), . , sistemas e sua criação e trazendo à condição de trabalho. Todo mundo tem sua própria motivação.

Não consigo imaginar que conseguiria isso em outra comunidade. Esses 10 anos foram incríveis. É curioso que a comunidade Erlang ainda seja pequena e seu potencial não seja revelado. Isso significa que há muitas oportunidades de participar de tudo, de se comunicar cara a cara com pessoas cheias de sabedoria e que desejam compartilhar isso e encontrar seu lugar.

PS. Obrigado por traduzir o e-mail do grupo; Comunidade Erlang no Telegram (Evgeny M., Sergey Ivanov, Vladimir Sekisov, Greg)