Erlang/OTP 29.0

 (erlang.org)
1 points par GN⁺ 5 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le daemon SSH désactive désormais par défaut les services shell et exec, empêchant ainsi les utilisateurs authentifiés d’exécuter du code Erlang arbitraire tant que cela n’est pas configuré explicitement
  • Au démarrage du daemon SSH, le sous-système SFTP n’est lui non plus plus activé par défaut, ce qui renforce les paramètres de sécurité par défaut
  • L’attribut -unsafe a été ajouté pour permettre de marquer les fonctions non sûres, et le compilateur génère désormais par défaut des avertissements pour les appels à des fonctions qu’Erlang/OTP considère toujours comme non sûres
  • xref peut détecter les appels à des fonctions non sûres ainsi que les fonctions non documentées, et le filtrage de l’attribut ignore_xref est maintenant géré directement par xref
  • Dans la configuration SSL par défaut, x25519mlkem768 est devenu le groupe d’échange de clés le plus privilégié, et l’algorithme d’échange de clés SSH par défaut a lui aussi été remplacé par mlkem768x25519-sha256, qui combine ML-KEM-768 et X25519
  • Dans le chemin de code par défaut du système Erlang, le répertoire de travail courant . a été déplacé de la première à la dernière position, modifiant ainsi l’ordre de chargement
  • Les builds Erlang/OTP 32 bits pour Windows ne sont plus fournis
  • Les native records de EEP-79 ont été implémentés et sont considérés comme une fonctionnalité expérimentale dans Erlang/OTP 29
  • Ajout du guard BIF is_integer/3, des compréhensions à valeurs multiples basées sur EEP 78, ainsi que de la liaison de variables à l’intérieur des compréhensions via la fonctionnalité compr_assign
  • Le compilateur ajoute désormais par défaut des avertissements pour catch, l’export de variables hors des sous-expressions, and/or, ainsi que pour les motifs d’alias de correspondance comme {a,B} = {X,Y}, avec des options de désactivation pour chacun
  • Les anciens guard tests seront retirés du langage dans Erlang/OTP 30, et les avertissements existants sur l’usage de guards obsolètes continuent de s’appliquer
  • io_ansi permet d’émettre des séquences ANSI/Virtual Terminal Sequence dans le terminal, et ct_doctest permet de tester les exemples présents dans la documentation des modules Erlang et dans les fichiers de documentation

À lire aussi

1 commentaires

 
GN⁺ 5 시간 전
Commentaires sur Hacker News

  • Les améliorations ont l’air plutôt bonnes. Le fait de désactiver par défaut le démon SSH ainsi que SFTP est un bon changement du point de vue de la sécurité
    Le module io_ansi a aussi l’air assez chouette. Aujourd’hui, Erlang n’est pas vraiment réputé pour la création d’applications en ligne de commande complexes, donc l’ajout à la bibliothèque standard pourrait beaucoup aider à l’avenir. La manière dont fwrite fonctionne naturellement entre les nœuds, c’est exactement le genre d’avantage qu’on attend d’Erlang
    L’ajout de Native Records est aussi intéressant. En ce moment, en Elixir, on a l’impression qu’on mélange records, tuples et maps selon les cas, donc je suis curieux de voir comment ce sera utilisé à l’avenir. Comme le dit l’EEP, les records existants ne vont sans doute pas disparaître complètement, mais cela semble être une amélioration importante
    https://www.erlang.org/doc/apps/ssh/ssh.html
    https://www.erlang.org/docs/29/apps/stdlib/io_ansi.html
    https://github.com/erlang/eep/pull/81

    • Je ne pense pas que le démon SSH se soit déjà activé ou lancé automatiquement. La formulation des deux points diffère, mais le sens semble être que, lorsqu’on démarre le démon SSH, les composants listés ne sont plus lancés par défaut
      Le démon SSH désactive désormais par défaut les services shell et exec, conformément au principe secure by default. Sauf configuration explicite, cela empêche un utilisateur authentifié d’exécuter du code Erlang arbitraire
      Le sous-système SFTP n’est lui non plus plus activé par défaut au démarrage du démon SSH

  • Pour ceux qui se demandent ce que signifie OTP dans Erlang/OTP, à l’origine c’est un ensemble de bibliothèques et de principes destiné aux télécoms, pour standardiser la création d’applications hautement fiables et tolérantes aux pannes
    L’idée de base vaut le coup d’être parcourue rapidement dans l’introduction des « OTP Design Principles »
    https://www.erlang.org/doc/system/design_principles.html

    • OTP = Open Telecom Platform

  • Si votre application en production est sur une version antérieure à 29, il peut être préférable de mettre à jour au plus vite vers cette version ou vers le dernier correctif. Je viens juste de déployer en production, et le scan de sécurité automatique a remonté 2 CVE CRITIQUES datées de février à mai 2026, ainsi que plusieurs éléments à risque élevé

    • Il y a une liste ?

  • Je me demande s’il y a encore des gens qui utilisent Erlang pour de nouveaux projets
    Je sais qu’il y a ici beaucoup d’amateurs d’Elixir, mais je parle d’Erlang pur
    Si vous utilisez encore Erlang, qu’est-ce qui vous le fait préférer à Elixir ?

    • Oui, rien que cette année. Un nouveau travail IoT basé sur AtomVM, un serveur d’applications écrit en Erlang, et un framework TUI encore en cours de développement
      Elixir ne m’apporte pas d’avantage concret par rapport à Erlang. Il a sûrement des qualités, mais Erlang correspond mieux à ma façon de penser. J’aimerais aussi aborder l’apprentissage ou l’entraide comme une activité sociale, mais je ne trouve pas vraiment d’endroit qui me convienne

  • Quelqu’un peut expliquer l’architecture interne ?

  • Je suis curieux de voir comment les records vont trouver leur place dans l’écosystème

    • J’étais sur le point de dire : « les records existent depuis des décennies, non ? », puis j’ai lu le changelog
      Intéressant. Je me demande s’il existera un jour un monde où Elixir compilera les maps en native records

  • Quelqu’un sait si WhatsApp repose encore sur Erlang ?

    • Oui
      Ils utilisent Erlang depuis le début des années 2010, et c’est à cette époque que l’industrie tech a découvert que WhatsApp supportait plus de 400 millions d’utilisateurs actifs avec une équipe d’environ 30 ingénieurs
      J’avais contacté à l’époque l’un de leurs ingénieurs, qui a gentiment répondu par e-mail à quelques questions lorsque je vivais aux États-Unis. On a fini par prendre un café, et nous sommes encore en contact aujourd’hui
      On peut dire qu’Erlang reste encore aujourd’hui une partie importante de WhatsApp
    • D’après leur présentation à Code BEAM Europe 2025, c’est encore très probablement le cas : https://www.youtube.com/watch?v=tC435RGwRCI
    • Je ne le sais pas de source directe, mais je suis parti en 2019, et les dépôts publics liés à Erlang chez WhatsApp sont toujours actifs. À ma connaissance, Erlang ne s’est pas diffusé à l’ensemble de Meta, donc si WhatsApp s’en était détaché, il y aurait eu peu de raisons de continuer à travailler sur Erlang ensuite
    • Oui. Un de mes anciens employés travaille là-bas maintenant
    • Oui. Ils utilisent Erlang, et Rust prend aussi de plus en plus de place

  • L’ajout du support de l’attribut -unsafe, parfait, le moment idéal pour tout réécrire en Rust /s

  • Franchement, je ne sais pas qui utilise Erlang. J’ai utilisé Rails puis essayé Phoenix, et j’ai trouvé beaucoup plus difficile d’aboutir à quelque chose
    Je ne comprends pas l’enthousiasme autour de Phoenix
    Pour un développeur solo, Rails est probablement le système de web app le plus productif. Les LLM écrivent aussi très bien du code Ruby on Rails. Même si le corpus d’entraînement Python est énorme, d’après mon expérience ils s’en sortent bien mieux qu’avec Django
    J’écris les applis expérimentales en Rails, puis je les réécris en Go quand elles se stabilisent. Quand le périmètre de l’application est flou, partir directement en Go consomme bien plus de tokens, alors que Rails est très efficace pour ça
    Aujourd’hui, React ou Angular ne sont même plus nécessaires, sur Rails j’utilise Hotwire et sur Go j’utilise HTMX
    Le forum Erlang lui-même utilise Discourse, écrit en Rails

    • J’écris des applications Elixir à plein temps depuis 2016. Mes clients sont très contents de ne pas voir de crashs. En pratique, toutes les applications que j’ai déployées en production ces dix dernières années ont eu 100 % de disponibilité, à l’exception des pannes matérielles, système ou réseau hors de mon contrôle
      Vous gagneriez à élargir un peu votre horizon
    • Rails n’est plus rapide que Phoenix qu’au tout début, grosso modo le premier jour de développement. Après ça, on se heurte à de la logique implicite, à des choses comme method_missing, et on perd davantage de temps à comprendre comment ça fonctionne
      Elixir/Phoenix est plus explicite sur ce point, donc bien plus confortable à long terme pour la maintenance, c’est-à-dire dès qu’on dépasse la première semaine. Il n’y a pas d’état caché, pas besoin de se demander d’où vient ModuleName.method(params), ni de configurer quoi que ce soit pour exécuter cette méthode : il suffit de lui passer les bons arguments. L’inconvénient, c’est surtout un écosystème de packages prêts à l’emploi plus réduit
    • Vous voulez deviner ce qu’utilise Ruby Discord ?
    • Ce qui rend surtout Phoenix intéressant, c’est OTP, les channels et LiveView. Cela dit, je ne pense pas que LiveView serait mon choix en 2026, et si vous n’avez pas besoin de ce genre de fonctionnalités, l’intérêt peut être moindre
      Ecto n’est pas mal non plus
      Claude Code écrit très bien du code Elixir
      De façon assez surprenante, avec ou sans LLM, on est plus productif avec une technologie qu’on connaît déjà
    • Il y a une ironie absolue à écrire « quand le périmètre de l’application est flou, partir directement en Go consomme bien plus de tokens, alors que Rails est très efficace pour ça ». Après tout ce discours, vous venez surtout de révéler que ce n’est même pas vous qui écrivez le code en question