Meu programa Erlang favorito (2013)

 (joearms.github.io)
2 pontos por GN⁺ 2023-09-09 | 1 comentários | Compartilhar no WhatsApp
  • Apenas com o trecho de notas fornecido, não é possível identificar qual é o programa Erlang do título nem por que ele é importante
  • O texto verificável consiste principalmente em trechos de script Shell e uma curta frase de correção
  • O script percorre os arquivos *.png.png.meta no diretório atual e extrai a parte do nome antes do primeiro ponto
  • O comando realmente executado é git mv $i $j.png.meta, e o comando para trocar $j.png.png por $j.png é apenas exibido na saída
  • Como o trecho original 5-104 foi omitido, não é possível confirmar a tese central relacionada ao título nem a explicação de qualquer código Erlang

Conteúdo verificável

  • Com o material fornecido, é difícil determinar a identidade do “programa Erlang favorito”, os motivos da preferência ou a estrutura do código
  • O trecho de código verificável é um script Shell para renomear arquivos que começa com #!/bin/sh
    • Ele itera sobre arquivos *.png.png.meta
    • Usa j="${i%%.*}" para extrair a parte do nome antes do primeiro ponto
    • git mv $i $j.png.meta é realmente executado
    • git mv $j.png.png $j.png é apenas mostrado com echo
  • Há a frase “Actually you don't need the really do this. It should have been water the plants.”, que parece corrigir uma instrução ou exemplo anterior, indicando que na verdade isso não era necessário e que deveria ter sido “water the plants”
  • No final, Joe Armstrong e Jeremy Ruston são mencionados juntos

Contexto que limita a análise

  • Vários trechos são compostos por metadados de estado/barra lateral do TiddlyWiki, dados Base64 que parecem ser JPEG/PNG e conteúdo vazio, o que dificulta extrair fatos do corpo principal
  • As notas fornecidas não incluem informações centrais como o funcionamento do programa Erlang, código, motivos de design, exemplos, números, fluxo de trabalho ou argumentos
  • O trecho de script Shell também foi fornecido apenas parcialmente e sem explicação ao redor, então não dá para afirmar de que tarefa ele faz parte

Faixa omitida

  • A entrada informa explicitamente que os trechos originais 5-104 foram omitidos por limite de tamanho/custo
  • Este resumo reflete apenas o intervalo de notas fornecido e não cobre os detalhes nem as conclusões do texto completo

Leituras relacionadas

1 comentários

 
GN⁺ 2023-09-09
Comentários do Hacker News

  • Se o closure de servidor F puder receber, além de suas próprias mensagens, uma mensagem {become, F}, dá para ir transformando continuamente o servidor em um novo comportamento
    É um assunto totalmente diferente, mas ficou na memória uma conversa que tive com Joe em uma conferência de Erlang. Ele estava sempre empolgado com tecnologia e conversava de bom grado com qualquer pessoa. Lamentava que o Windows ficasse pior e menos utilizável a cada ano, e dizia que um dia, para ver um arquivo, seria preciso assistir a anúncios por um tempo até ele ser desbloqueado; ele quase acertou. O Windows 11 já tem anúncios, e para removê-los é preciso procurar deliberadamente nas configurações, então lá pelo Windows 13 acho que isso realmente vai acontecer

    • Em casa uso Linux e no trabalho uso Windows, e o que me surpreendeu mais do que os anúncios foi que, no Windows, vejo com muito mais frequência aqueles problemas estranhos que antes eu só via no Linux antigo
      Coisas como um lado do fone ficar muito mais alto, apps da Microsoft fecharem de forma esquisita, páginas da documentação do Windows não abrirem em nenhum navegador e eu ter de usar sites de arquivo, um monitor externo que funcionava bem de repente não ser detectado, ou a tela piscar. O Office, por padrão, incentiva a salvar na nuvem em vez de localmente, mas eu prefiro que os arquivos sejam local-first e que a nuvem sirva como backup. O WSL é bem tosco, mas ainda assim é praticamente o único motivo que torna o Windows utilizável
      Sempre ouvi dizer que Joe era uma pessoa excelente, e isso faz sentido. Quando eu estava aprendendo programação sozinho, li o livro dele sobre Erlang, e o espírito brincalhão, a humildade e a imaginação dele tiveram um grande impacto. Acabei quase não usando Erlang, mas os textos dele mudaram minha forma de pensar sobre código, e eu gostaria que a cultura da matemática, da engenharia de software e da ciência da computação aceitasse mais brincadeira e humildade
    • O conteúdo do primeiro parágrafo é, na verdade, uma capacidade do modelo de atores. Eu não sabia antes que isso também era possível na BEAM
    • Anúncios invasivos no Windows 11 não são uma novidade. Eles já existem no Windows 10

  • Um vídeo curto, de 35 minutos, explicando por que a BEAM é diferente de outras máquinas virtuais como a JVM ou o Node: https://www.youtube.com/watch?v=pO4_Wlq8JeI

    • Vi uma apresentação parecida, The Soul of Erlang and Elixir, e ela é excelente; fico animado de novo toda vez que assisto

  • Sinto falta do Joe. A paixão contagiante dele por tornar a computação melhor marcou profundamente quem eu era quando jovem e a forma como abordo tecnologia hoje

  • universal_server() -> receive {become, F} -> F() end.
    Sinceramente, não entendo totalmente o poder desse universal_server. Seria ótimo se alguém explicasse

    • Se você conhece Go, é parecido com uma goroutine esperando que alguém envie uma função anônima para ela executar
      Em Erlang, você resolve problemas iniciando muitos processos, e a maioria deles fica esperando mensagens. A diferença importante é que processos Erlang podem executar de forma transparente também em máquinas remotas. Esse processo recebe uma mensagem em forma de tupla contendo o átomo become e uma função; quando outro processo envia essa mensagem a qualquer momento, ele “se transforma” nessa função
      Ou seja, é possível trocar a lógica do loop de espera pela lógica de protocolo que você quiser. No exemplo, eles iniciaram esse loop em várias máquinas e enviaram uma função que implementava um protocolo de gossip, mas do mesmo jeito seria possível enviar uma mensagem para que ele se tornasse um cliente BitTorrent. Joe era um gênio e também uma pessoa muito gentil, e Erlang é uma das criações técnicas mais bonitas que já vi. Ele faz você enxergar concorrência de um jeito completamente novo
    • Explicando um pouco mais, a palavra-chave receive é como um switch para mensagens recebidas, mas na verdade é pattern matching
      Por exemplo, dá para criar um servidor de fatorial que recebe {From, N} e devolve o resultado com From ! factorial(N). O ! é o operador que envia o resultado ao processo de retorno
      O código de teste inicia o universal_server, faz com que ele vire um servidor de fatorial com Pid ! {become, fun factorial_server/0} e então envia {self(), 50} para receber o fatorial de 50. Uma grande vantagem do Erlang é o paralelismo distribuído e as atualizações de código a quente, e aqui isso aparece como a substituição do loop de recebimento do universal_server pelo loop de recebimento do factorial_server. Dito isso, acho que atualizações reais de código a quente não funcionam exatamente dessa forma
    • Normalmente, é preciso saber de antemão para que um servidor será usado e escrever o código com isso em mente
      Mas em Erlang você pode criar uma rede distribuída de servidores Erlang e deixar os servidores como recursos computacionais de uso geral, capazes de fazer o que o cliente quiser. O código vem do cliente; em vez de pedir ao administrador do sistema para instalar binários em todas as máquinas, você passa uma função e a máquina remota a chama
    • O ponto central é que ele pode se transformar em qualquer tipo de servidor que você queira
      A função real que executará o servidor é passada pelo cliente, e o processo Erlang se torna aquele servidor com base nessa função. Considerando ainda a capacidade de hot reloading do Erlang, essa estrutura simples fica ainda mais poderosa. Um processo Erlang é um recurso computacional esperando trabalho; se esse trabalho for executar um servidor completo, isso é bem interessante
    • A estrutura do Erlang é peculiar: tanto a máquina virtual quanto a linguagem são construídas sobre a ideia de pequenos processos rodando simultaneamente, cada um esperando em um loop infinito para interpretar mensagens recebidas
      Por isso, um processo pode se tornar qualquer coisa dependendo do código que você envia. Se ele precisa controlar um micro-ondas, depois fazer computação quântica e no dia seguinte prever o vencedor de uma partida de futebol, basta enviar o código necessário para cada tarefa e ele executa

  • Passei muito tempo explicando por que a BEAM é especial e por que a concorrência em Erlang/Elixir etc. é diferente da concorrência em Go ou Java
    De agora em diante, acho que basta linkar o programa Erlang favorito do Joe e esta thread do HN

  • Este post do blog também foi abordado em uma ótima apresentação recente: https://youtu.be/pQ0CvjAJXz4

    • É uma apresentação que cobre e explica muito bem cada etapa da arquitetura de alta disponibilidade, tolerância a falhas e sistemas Erlang distribuídos
    • Fico me perguntando se é aquele sistema em que cada paciente é representado por um processo Erlang

  • Tenho apenas uma compreensão de alto nível da linguagem Erlang e nunca programei diretamente nela, mas fiquei curioso sobre por que este código é necessário
    universal_server() -> receive {become, F} -> F() end.
    Fico pensando se não bastaria iniciar F() diretamente na máquina remota. Como o código de F já precisaria existir na máquina virtual remota, talvez este exemplo queira dizer que o código de F é serializado e enviado. Se ele trata boilerplate comum, entendo sua utilidade, mas, do jeito que está, parece esperar a mensagem become F e então executar F()

    • Esse código é legal, mas pode não ser muito idiomático nem algo visto com frequência em código de produção real. Ainda assim, Joe gostava de explorar e experimentar
      Aqui, F é um closure, então pode incluir não só o código, mas também as variáveis capturadas e o ambiente do momento em que foi criado. Ao chamar F(), esse código é executado e pode acessar o ambiente ao redor de quando F foi criado
      Em Erlang, é possível enviar closures para outro nó Erlang pela rede. Porém, o código dos módulos referenciados pelo closure precisa existir em todos os nós. Em código de produção, como você disse, é mais provável chamar diretamente o módulo de F e passar os argumentos de forma explícita; isto está mais para uma demonstração interessante das possibilidades
    • Graças ao design funcional de Erlang, F() pode ser um contexto de nível superior tão bom quanto qualquer contexto anterior, o que é ótimo
      Dá para fazer com que requisições existentes sejam tratadas naturalmente pela lógica antiga, enquanto novas requisições começam com a nova lógica e, no fim, a lógica antiga possa ser coletada pelo garbage collector
    • É verdade que o código de F já precisa existir na máquina virtual remota, mas também é possível enviar código para a máquina virtual remota
      Por exemplo, em Elixir, com Code.compile_string, é possível obter o nome do módulo e o binário do bytecode BEAM. Você pode enviar esse bytecode para outra máquina virtual e carregá-lo na VM remota com :rpc.call('node@remote_host', :code, :load_binary, [the_module_name, "filename_doesnt_really_matter", binary_code]); depois, iniciá-lo com spawn('node@remote_host', my_module, my_function, [args])
    • O programa citado foi pensado para ser executado em uma máquina remota, e a máquina remota desserializa o programa que deve executar em seguida
      Aqui, F é uma variável que representa o novo programa serializado e enviado como mensagem entre processos; neste caso, ele também é transmitido pela rede

  • Também há uma palestra em que Joe explica como escrever um servidor básico em Erlang: https://gioorgi.com/2015/erlang-lesson1/
    Eu a transcrevi e acrescentei um pouco mais de explicação, e ela mostra a força que linguagens assíncronas como Erlang/Elixir têm em comparação com outras linguagens. Infelizmente, hoje em dia elas não são tão usadas

  • Ultimamente estou mergulhado em Julia, e parece que ela tomou emprestadas várias ideias de Erlang em seu modelo distribuído
    Esses servidores improvisados que funcionam quase por mágica em vários nós também podem ser reproduzidos com bastante facilidade em Julia. Não tenho certeza, mas parece improvável que o módulo Distributed de Julia não tenha se inspirado nem um pouco em Erlang
    Gosto muito de Erlang e gostaria de ter mais oportunidades de usá-la, mas também é bom ver esses conceitos se infiltrando em outras plataformas

    • Acho que estaríamos do mesmo lado ao tentar convencer a comunidade Julia sobre lições como let it crash, vindas da filosofia de Erlang para relatório de erros