Lançamento do Elixir 1.17: tipos por teoria dos conjuntos em padrões, Duration e OTP 27

 (elixir-lang.org)
1 pontos por GN⁺ 2024-06-13 | 1 comentários | Compartilhar no WhatsApp
  • Tipos graduais por teoria dos conjuntos adicionados para inferir tipos a partir de padrões e emitir avisos em tempo de compilação, ajudando a encontrar defeitos e bugs na base de código sem exigir mudanças no software existente
  • Os novos avisos de tipo atualmente focam em atom e map/struct, detectando pattern matching com chaves inexistentes, acesso a campos inexistentes, chamadas de função em não-módulos, chamadas inválidas de funções anônimas, comparação estrutural entre structs, comparação entre tipos sem interseção, padrões binary inválidos e rescue de exceções não definidas
  • O verificador de tipos atualmente infere tipos apenas a partir de padrões dentro da mesma função; análises entre guards e fronteiras de funções estão previstas para versões futuras
  • Adicionado suporte ao Erlang/OTP 27 e encerrado o suporte ao Erlang/OTP 24; a migração para Erlang/OTP 26 ou superior é recomendada, incluindo no Windows
  • O suporte ao WERL, a interface gráfica de terminal do Erlang no Windows, será removido no Elixir v1.18
  • Adicionados o novo tipo de dado Duration e Date.shift/2, permitindo deslocar datas, horários e datetimes com base em duration; no DateTime, isso inclui mudanças de fuso horário e tratamento de horário de verão
  • Adicionado Kernel.to_timeout/1 para normalizar duration e integer em valores de timeout usados por várias APIs, como Process e GenServer
  • O recurso de process label do Erlang/OTP 27 pode ser usado no Elixir com Process.set_label/1, e o Logger agora formata relatórios do gen_statem e inclui process labels do Erlang/OTP 27 em eventos de log
  • Adicionados Keyword.intersect/2,3, o novo profiler do Mix mix profile.tprof e o guard Kernel.is_non_struct_map/1 para reduzir a armadilha de %{} também corresponder a structs
  • Com a adição de mix profile.tprof, mix profile.cprof e mix profile.eprof passam a ser soft-deprecated

Leituras relacionadas

1 comentários

 
GN⁺ 2024-06-13
Opiniões no Hacker News

  • Nos últimos anos, o ecossistema Elixir vem se tornando a solução mais simples para muitos tipos de uso
    Com Phoenix e LiveView, o desenvolvimento web é rápido e prazeroso; com NX/Axon/Bumblebee, dá para fazer inteligência artificial; com Membrane, streaming e processamento de áudio e vídeo; com Commanded, CQRS e event sourcing; com Nerves, criar dispositivos embarcados; e, com o LiveView Native, ainda em desenvolvimento, até apps móveis
    Filas, pipelines e processamento em lote também podem ser tratados conforme a necessidade, com recursos nativos ou com GenStage, Broadway e Oban
    Ainda assim, pessoalmente, o recurso central é o IEx, o REPL do Elixir. Poder interagir diretamente com código em desenvolvimento ou em produção, inspecionar por dentro e depurar é algo que muda a vida
    A chegada de tipos a isso é a última peça do quebra-cabeça para termos mais confiança no código que colocamos em produção

    • Além disso, o ExUnit torna os testes extremamente fáceis, o gerenciador de pacotes Hex simplesmente funciona bem, e o FLAME permite escalar processos para outro computador com quase uma única linha de código
      O Ecto permite lidar com bancos de dados SQL de forma funcional; ainda não sei exatamente como encarar ORMs, mas, se com algumas consultas componíveis foi possível eliminar 90% do SQL, considero um sucesso
      Depois de passar meses sofrendo com deploy, tempo de atividade, falhas de segmentação, tempos de pacotes e afins, migrei o servidor web e a camada de dados para Elixir + Phoenix, e agora tudo está muito mais bem testado, mais fácil de raciocinar, com escalabilidade mais confiável e deploy mais simples
      Graças à convenção em vez de configuração, foi absurdamente rápido começar com Phoenix, muito mais rápido do que com FastAPI. Fico pensando que deveria ter feito isso meses antes
      Agora estou treinando modelos com Nx, experimentando Bumblebee/Livebook e adicionando recursos de presence e live ao app praticamente de graça
    • Fazendo uma leve propaganda do LiveView Native: além de apps móveis, também dá para criar para desktop, relógios, TVs e Apple Vision Pro
      Tudo usando os mesmos conceitos, desempenho e conveniência de desenvolvimento do LiveView
    • Vindo de uma linguagem com um sistema de tipos estático poderoso e útil, essa é a lacuna que mais sinto, por isso estou olhando para o Gleam com curiosidade
      Acho que seria difícil voltar para algo como Erlang ou Elixir
    • Concordo que o REPL do Elixir é de altíssimo nível e é o verdadeiro recurso matador da linguagem
      Sinto muita falta dele toda vez que escrevo código em outras linguagens, especialmente quando estou programando profissionalmente
      Um bom REPL reduz muito o atrito comum na programação. Em vez de rodar o app inteiro para cutucar um trecho problemático de código, você pode construir ideias aos poucos e testá-las na hora
      A biblioteca padrão do Elixir também é excelente, e é muito fácil acessar a documentação pelo REPL, o que ajuda muito a manter o fluxo. Quando programo em Elixir, raramente abro o navegador para pesquisar pequenas dúvidas, porque geralmente encontro a resposta sem sair do REPL
      Isso também me incentiva a escrever boas docstrings no meu próprio código
      O melhor ainda é poder rodar o REPL junto com o código em execução. Mesmo quando preciso executar o app, posso deixá-lo rodando e, no ambiente de desenvolvimento, manipular dados ao vivo e examinar o estado interno. Em outras stacks, isso é impossível ou exige um depurador
      Com a chegada dos recursos relacionados a tipos, espero que as ferramentas fiquem ainda melhores
      Some a isso a diversão e a força do paradigma funcional, além de formas robustas de lidar com mutabilidade e estado, sem precisar encarar a sintaxe de LISP. Pessoalmente, é uma linguagem que acerta todas as notas para mim, e eu gosto muito dela
    • Outras linguagens também não têm bastante coisa assim? Ruby tem o IRB
      O IEx faz algo que o IRB não faz?

  • Nos últimos anos, as equipes de Elixir e Erlang têm feito um trabalho realmente muito bom, sem falar no trabalho de autores de bibliotecas e livros
    Nunca fiquei tão ansioso por um lançamento. Acompanhei commits de Elixir e OTP por um tempo, e a sensação é de que Elixir/Erlang definitivamente ganharam tração

  • Estou usando Elixir no backend de um projeto paralelo, e o frontend é em Remix; trabalhar no backend tem sido muito agradável e produtivo
    Reconheço a produtividade do LiveView, mas no meu caso preciso lidar com conexões de rede instáveis, então, como esperado, a experiência com LiveView não foi boa
    Gostaria que, na cabeça dos desenvolvedores, Elixir fosse um pouco mais separado de LiveView. Mesmo usado só como um backend de API simples, sem LiveView nem canais em tempo real, Elixir é realmente divertido

    • Gosto muito de Elixir, uso para quase tudo, e LiveBook virou meu ponto de partida padrão para começar a criar software de brinquedo
      Mas não me dou bem com LiveView. É bem difícil de entender e há muitas armadilhas pelo caminho. Por exemplo, às vezes é preciso lembrar de tratar verificações de autenticação tanto no pipe_through do roteador quanto no callback on_mount do LiveView. Veja [0]
      O simples fato de a frase acima não significar nada para um desenvolvedor que está começando com Phoenix e LiveView já é prova suficiente de que LiveView não deveria ser o modo padrão
      Isso cria uma curva de aprendizado muito íngreme onde ela não é necessária. Elixir/Phoenix em si é fácil
      Para um desenvolvedor aprendendo Elixir/Phoenix agora, acho que a sequência certa é primeiro usar as dead views do Phoenix no estilo MVC e, depois, ler “Elixir in Action” para aprender o básico de OTP. O livro é fácil, abriu meus olhos e mudou quase tudo no meu jeito de programar
      Só então acho melhor passar para LiveView
      [0]: https://hexdocs.pm/phoenix_live_view/security-model.html#liv...
    • Se você executar mix phx.new com a flag —no-live, pode usar Phoenix sem LiveView. Em projetos existentes, também dá para removê-lo manualmente
    • As respostas até agora estão perdendo o ponto principal
      O problema não é conhecimento técnico nem padrões de instalação, mas a percepção dos desenvolvedores. Muita gente pensa em Elixir e no restante do ecossistema a partir de LiveView, e acaba ignorando todo o resto
      Elixir é muito mais do que isso, e até Phoenix é maior que LiveView
      Dá perfeitamente para criar aplicações Elixir produtivas e eficientes em custo mesmo sem LiveView e, claro, até sem Phoenix. Escolher Elixir no backend deveria ser mais comum do que é hoje, mas também entendo os lugares-comuns e os receios que levam a outras escolhas

  • Estou construindo minha startup com Elixir 100% full-stack, e é a melhor tecnologia que já usei até agora
    Fico evangelizando para meus amigos técnicos mais sérios sobre o quanto ela é boa
    Agora seria ótimo se RabbitMQ e seu cliente rodassem no OTP 27. Quero fazer o upgrade

    • Fico curioso para saber que tipo de coisa você está fazendo para sentir que Elixir está exatamente no ponto ideal em relação a outras tecnologias
    • RabbitMQ é bem robusto; vocês estão enfrentando algo como vazamento de desempenho?
      Usamos login de clientes com certificados SSL há anos e estamos muito satisfeitos com a estabilidade

  • Por mais elogios que eu faça a Elixir e Phoenix, ainda é pouco. Com tipos chegando agora, vai ficar ainda melhor
    Você vai ouvir muito sobre a BEAM e seu poder, mas, pela minha experiência, dá para ir muito longe antes de chegar ao ponto em que precisa pensar nessa parte da stack. Phoenix abstrai isso muito bem, então você obtém os benefícios sem esforço
    Um exemplo é o Oban. Dentro do Postgres, você ganha tarefas em segundo plano poderosas, flexíveis e fáceis de usar, escritas em código Elixir, quase de graça. É realmente impressionante
    Recomendo experimentar

    • Eu concordaria totalmente se não fosse pelo LiveView
      Por causa do LiveView e da obsessão de marketing ao redor dele, pessoas que, de outra forma, poderiam passar mais tempo sem conhecer OTP acabam encontrando OTP muito cedo na jornada, talvez já na primeira rota de controller
      Escrever e testar bem um fluxo robusto em LiveView é tão intelectualmente complexo quanto escrever um GenServer stateful com vários fluxos não lineares e diversos pontos de entrada via call/cast
      LiveView usa outros termos e tem pequenas camadas de conveniência, como async assigns, mas mecanicamente ele é literalmente um GenServer. Acho importante entender bem isso para usá-lo de forma eficaz
      Gosto muito do Oban e sinto muita falta dele em outros ecossistemas

  • À parte: alguém já usou elixir-desktop [1]? É um pacote de wxWidgets + LiveView, então é bem parecido com um app Electron
    Em [2], Wojtek Mach explica como a equipe do Elixir criou o Livebook Desktop. Ele cobre como o projeto começou, bugs sutis descobertos ao criar o app para macOS, limitações do wxWidgets no Windows e vários detalhes de implementação
    Seria bom se a equipe do Elixir lançasse oficialmente algo como elixir-desktop baseado no Livebook. Ou seja, fornecer um projeto de template oficial que fizesse um fork do repositório do Livebook para criar aplicações desktop baseadas em LiveView
    Hoje, o Livebook é distribuído como executáveis para Windows e Mac. Que tal seguir a mesma abordagem para permitir que desenvolvedores distribuam executáveis independentes, como no Electron?
    Também conheço o LiveView Native [3], mas acho que é uma direção diferente
    [1] https://github.com/elixir-desktop/desktop-example-app
    [2] https://www.youtube.com/watch?v=Kiw6eWKcQbg
    [3] https://native.live/

  • Estou ansioso pelo dia em que a desculpa de que não há tipos deixará de ser um obstáculo à popularização do Elixir

  • Há 10 anos leio ótimas histórias sobre Elixir por aqui, e também gosto da linguagem
    Mas desisti de procurar vagas em Elixir alguns anos atrás, porque os salários continuavam parecendo mais baixos do que em linguagens mainstream
    Talvez seja a linguagem que eu mais queira usar, mas, para mim, salário e um produto interessante são mais importantes do que a stack tecnológica, então talvez eu acabe não trabalhando com ela de fato. Ainda assim, continua sendo divertido acompanhar de longe

    • Como desenvolvedor Elixir, soa surpreendente que os salários sejam mais baixos do que em linguagens mainstream
      Fico curioso se você está procurando nos EUA ou em outra região
    • Os salários costumam ser consistentemente mais altos do que em stacks mainstream. Em parte porque a maioria das vagas de Elixir procura engenheiros sênior

  • Um bom recurso desta versão é a adição de get_in/1, que funciona com structs. Por exemplo, dá para usar como get_in(struct.foo.bar)
    Se foo retornar nil, o acesso a bar não gera uma exceção

    • Isso já era possível em versões anteriores do Elixir, mas a sintaxe era verbosa
      Para níveis que não eram mapas comuns, era preciso usar Access.key, assim
      get_in(struct, [Access.key(:foo), :bar])

  • Esta é a última peça que eu queria. Estou ansioso pelos próximos passos
    Fora isso, para mim, a linguagem está funcionalmente 100% completa

    • Da última vez que olhei para Elixir, parecia haver um consenso de que “no fim, você também precisa lidar com Erlang”
      Isso ainda é verdade hoje, ou não é mais necessário descer para Erlang?