Sortie d’Elixir 1.17 : types en théorie des ensembles pour les patterns, Duration, OTP 27

• Les types en théorie des ensembles progressifs infèrent les types à partir des patterns et émettent des avertissements à la compilation, ajoutant une capacité à détecter des défauts et des bugs dans une base de code sans modifier le logiciel existant
• Les nouveaux avertissements de type se concentrent actuellement sur les atom et les map/struct, et détectent les pattern matchings sur des clés inexistantes, les accès à des champs inexistants, les appels de fonctions sur des non-modules, les appels invalides de fonctions anonymes, les comparaisons structurelles entre structs, les comparaisons entre types disjoints, les patterns binary invalides et les rescue d’exceptions non définies
• Le vérificateur de types infère actuellement les types uniquement à partir des patterns au sein d’une même fonction ; l’analyse des guards et entre les frontières de fonctions est prévue dans de futures versions
• La prise en charge d’Erlang/OTP 27 est ajoutée et celle d’Erlang/OTP 24 est abandonnée ; une migration vers Erlang/OTP 26 ou supérieur est recommandée, y compris sous Windows
• La prise en charge de WERL, l’interface graphique de terminal Erlang pour Windows, sera supprimée dans Elixir v1.18
• Le nouveau type de données Duration et Date.shift/2 sont ajoutés, permettant de décaler des dates, heures et date-times à l’aide d’une duration ; dans DateTime, cela gère aussi les changements de fuseau horaire et l’heure d’été
• Kernel.to_timeout/1 est ajouté pour normaliser les duration et les entiers en valeurs de timeout utilisées par diverses API comme Process et GenServer
• La fonctionnalité de label de processus d’Erlang/OTP 27 est disponible dans Elixir via Process.set_label/1, et Logger formate les rapports gen_statem et inclut les labels de processus d’Erlang/OTP 27 dans les événements logger
• Ajout de Keyword.intersect/2,3, du nouveau profiler Mix mix profile.tprof, et du guard Kernel.is_non_struct_map/1 pour réduire le piège où %{} matche aussi les structs
• Avec l’ajout de mix profile.tprof, mix profile.cprof et mix profile.eprof passent en soft-deprecation

[GN⁺]

Réactions sur Hacker News

• Ces dernières années, l’écosystème Elixir est vraiment en train de devenir la solution la plus simple pour un très grand nombre d’usages
  Avec Phoenix et LiveView, le développement web est rapide et agréable ; avec NX/Axon/Bumblebee, on peut faire de l’IA ; avec Membrane, du streaming et du traitement audio/vidéo ; avec Commanded, du CQRS et de l’event sourcing ; avec Nerves, créer des appareils embarqués ; et même des applications mobiles avec LiveView Native, actuellement en développement
  Les files d’attente, les pipelines et le traitement par lots peuvent aussi être gérés via les fonctionnalités de base ou avec GenStage, Broadway et Oban selon les besoins
  Malgré tout, à mes yeux, la fonctionnalité centrale reste IEx, le REPL d’Elixir. Pouvoir interagir directement avec le code en développement ou en production, l’inspecter et le déboguer, c’est le genre de chose qui change la vie
  L’ajout des types vient compléter la dernière pièce du puzzle pour donner davantage de confiance dans le code que nous déployons

  • En plus de cela, ExUnit rend les tests incroyablement simples, le gestionnaire de paquets Hex fonctionne tout simplement bien, et FLAME permet quasiment d’étendre des processus sur une autre machine avec une seule ligne de code
    Ecto permet de manipuler des bases de données SQL de manière fonctionnelle ; je ne sais toujours pas exactement comment considérer les ORM, mais le fait d’avoir pu éliminer 90 % du SQL avec quelques requêtes composables me semble être une réussite
    Après avoir passé des mois à souffrir de déploiements, de disponibilité, de segmentation faults et de temps perdus côté paquets, nous avons migré notre serveur web et notre couche de données vers Elixir + Phoenix, et tout est désormais bien mieux testé, plus facile à raisonner, plus fiable à faire évoluer et plus simple à déployer
    Grâce à la convention plutôt que la configuration, il a été incroyablement rapide de démarrer avec Phoenix, bien plus rapide qu’avec FastAPI. J’aurais dû le faire des mois plus tôt
    Maintenant, j’entraîne des modèles avec Nx, j’expérimente Bumblebee/Livebook, et j’ajoute à l’application des fonctions de presence et de live presque gratuitement
  • Pour faire un peu de promo pour LiveView Native : on peut créer non seulement des applications mobiles, mais aussi pour desktop, montres, TV et Apple Vision Pro
    Le tout en conservant les concepts, les performances et le confort de développement de LiveView
  • En venant de langages dotés de systèmes de types statiques puissants et utiles, c’est le manque qui m’a toujours le plus pesé, donc je regarde Gleam avec curiosité
    Je ne pense pas pouvoir revenir facilement vers des choses comme Erlang ou Elixir
  • Le REPL d’Elixir est de tout premier ordre, et je suis d’accord pour dire que c’est la vraie fonctionnalité killer du langage
    Chaque fois que j’écris du code dans un autre langage, surtout quand je suis payé pour ça, ça me manque énormément
    Un bon REPL réduit énormément les frictions habituelles de la programmation. Au lieu de lancer toute l’application pour aller piquer un bout de code problématique, on peut construire une idée petit à petit et la tester au fur et à mesure
    La bibliothèque standard d’Elixir est aussi excellente, et l’accès à la documentation depuis le REPL est extrêmement simple, ce qui aide beaucoup à garder le flow. Quand je code en Elixir, j’ouvre rarement le navigateur pour chercher la réponse à une petite question, parce qu’en général je peux la trouver sans quitter le REPL
    Du coup, cela pousse aussi à écrire de bonnes docstrings dans mon propre code
    Encore mieux, on peut lancer le REPL avec le code en cours d’exécution. Même quand l’application doit tourner, elle continue de tourner, et dans un environnement de développement on peut manipuler des données live et inspecter l’état interne. Sur d’autres stacks, c’est impossible ou cela demande un débogueur
    Maintenant que des fonctionnalités liées aux types arrivent aussi, je m’attends à ce que l’outillage s’améliore encore
    Ajoutez à cela le plaisir et la puissance du paradigme fonctionnel, une manière robuste de gérer la mutabilité et l’état, sans avoir à supporter la syntaxe LISP. Personnellement, c’est un langage qui coche toutes les cases pour moi
  • Est-ce que d’autres langages n’ont pas déjà plus ou moins ça ? Ruby a IRB
    IEx apporte-t-il quelque chose qu’IRB n’a pas ?

• Ces dernières années, les équipes Elixir et Erlang ont vraiment fait un excellent travail, sans oublier celui des auteurs de bibliothèques et de livres
  Je n’avais pas été aussi impatient pour une release depuis longtemps. J’ai suivi les commits Elixir et OTP pendant un bon moment, et j’ai vraiment l’impression qu’Elixir/Erlang a pris de l’élan

• J’utilise Elixir pour le backend d’un side project et Remix pour le frontend, et travailler sur le backend est vraiment agréable et productif.
  Je reconnais la productivité de LiveView, mais dans mon cas je dois gérer des connexions réseau instables, donc l’expérience LiveView n’a pas été bonne, comme on pouvait s’y attendre.
  J’aimerais qu’Elixir soit un peu plus dissocié de LiveView dans l’esprit des développeurs. Même utilisé uniquement comme backend d’API simple, sans LiveView ni canaux temps réel, Elixir est vraiment très plaisant.

  • J’aime vraiment Elixir, au point de l’utiliser pour presque tout, et LiveBook est devenu mon point de départ par défaut pour commencer à bricoler des logiciels.
    Mais je n’arrive pas à bien utiliser LiveView. C’est assez difficile à comprendre et il y a beaucoup de pièges. Par exemple, il faut parfois penser à gérer les vérifications d’authentification à la fois dans le pipe_through du routeur et dans le callback on_mount de LiveView. Voir [0].
    Le simple fait que cette phrase ne veuille rien dire pour un développeur qui découvre Phoenix et LiveView suffit à montrer que LiveView ne devrait pas être l’approche par défaut.
    Cela crée une courbe d’apprentissage très raide là où elle n’est pas nécessaire. Elixir/Phoenix en lui-même est simple.
    Pour quelqu’un qui apprend Elixir/Phoenix, je pense qu’il vaut mieux commencer par les dead views de Phoenix en style MVC, puis lire Elixir in Action pour apprendre les bases d’OTP. Ce livre est accessible, m’a vraiment ouvert les yeux et a changé presque toute ma manière de coder.
    Et seulement après, passer à LiveView.
    [0]: https://hexdocs.pm/phoenix_live_view/security-model.html#liv...
  • On peut utiliser Phoenix sans LiveView en lançant mix phx.new avec le flag —no-live. On peut aussi le retirer manuellement d’un projet existant.
  • Les réponses postées jusqu’ici passent à côté du sujet.
    Le problème n’est pas une question de connaissances techniques ou de valeurs par défaut à l’installation, mais de perception chez les développeurs. Trop de gens associent d’abord Elixir, et même tout le reste de l’écosystème, à LiveView, puis ignorent tout le reste.
    Elixir, c’est bien plus que cela, et même Phoenix est plus vaste que LiveView.
    On peut tout à fait créer des applications Elixir productives et rentables sans LiveView, et même sans Phoenix. Elixir devrait être choisi plus souvent pour le backend qu’il ne l’est aujourd’hui, même si je comprends les idées reçues et les craintes qui poussent à faire d’autres choix.

• Je construis ma startup en full stack 100 % Elixir, et c’est de loin la meilleure technologie que j’aie utilisée jusqu’ici.
  Je n’arrête pas d’évangéliser mes amis tech sérieux sur à quel point c’est bien.
  Maintenant, ce serait vraiment bien que RabbitMQ et son client tournent sous OTP 27. J’ai envie de faire la mise à niveau.

  • Je suis curieux : sur quel type de travail est-ce que tu as l’impression qu’Elixir tombe pile au bon endroit par rapport aux autres technos ?
  • RabbitMQ est plutôt robuste, non ? Tu rencontres des problèmes comme des fuites de performances ?
    Nous utilisons depuis des années une méthode de connexion client avec certificats SSL, et nous sommes très satisfaits de sa stabilité.

• On ne dira jamais assez de bien d’Elixir et Phoenix. Avec les types en plus, ce sera encore mieux.
  On entend beaucoup parler de BEAM et de sa puissance, mais d’après mon expérience on peut aller très longtemps avant d’avoir réellement besoin de penser à cette partie de la stack. Phoenix l’abstrait remarquablement bien, donc on bénéficie des avantages sans effort.
  Oban en est un bon exemple. On obtient presque gratuitement, dans Postgres et avec du code Elixir, des tâches de fond puissantes, souples et faciles à utiliser. C’est vraiment impressionnant.
  Je recommande d’essayer.

  • J’aurais été entièrement d’accord sans LiveView.
    À cause de LiveView et de l’obsession marketing qui l’entoure, des gens qui, autrement, auraient pu rester plus longtemps sans connaître OTP se retrouvent confrontés à OTP très tôt dans leur parcours, peut-être dès leur première route de contrôleur.
    Écrire un flux LiveView solide et bien testé est intellectuellement aussi complexe qu’écrire un GenServer avec état, avec plusieurs flux non linéaires et différents points d’entrée call/cast.
    LiveView utilise d’autres termes et ajoute de petites couches de confort comme les async assigns, mais mécaniquement, c’est littéralement un GenServer. À mon avis, il est important de bien comprendre cela pour l’utiliser efficacement.
    J’adore vraiment Oban, et il me manque énormément dans les autres écosystèmes.

• Au passage, est-ce que quelqu’un a essayé elixir-desktop [1] ? C’est un ensemble wxWidgets + LiveView, assez proche d’une application Electron.
  Dans [2], Wojtek Mach explique comment l’équipe Elixir a créé Livebook Desktop. Il y parle de la manière dont le projet a démarré, des bugs subtils découverts en créant l’application pour macOS, des limites de wxWidgets sous Windows, et de nombreux détails d’implémentation.
  J’aimerais que l’équipe Elixir sorte officiellement quelque chose comme elixir-desktop sur la base de Livebook. Par exemple, en forkant le dépôt Livebook pour fournir un projet modèle officiel permettant de générer des applications desktop basées sur LiveView.
  Livebook est actuellement distribué sous forme d’exécutables pour Windows et Mac. Pourquoi ne pas suivre la même approche pour permettre aux développeurs de distribuer des exécutables autonomes, comme avec Electron ?
  Je connais aussi LiveView Native [3], mais je pense que c’est une direction différente.
  [1] https://github.com/elixir-desktop/desktop-example-app
  [2] https://www.youtube.com/watch?v=Kiw6eWKcQbg
  [3] https://native.live/

• J’attends avec impatience le jour où disparaîtra l’excuse « il n’y a pas de types » qui freinait l’adoption d’Elixir.

• Cela fait 10 ans que je lis ici de superbes discussions sur Elixir, et j’aime aussi le langage
  Mais j’ai abandonné l’idée de chercher un poste en Elixir il y a quelques années. Les salaires me semblaient systématiquement plus bas que pour les langages grand public
  C’est peut-être le langage que j’ai le plus envie d’utiliser, mais pour moi le salaire et un produit intéressant comptent davantage que la stack technique, donc au final je ne pourrai peut-être pas le faire. Cela dit, c’est toujours amusant de suivre ça de loin

  • En tant que développeur Elixir, je suis surpris d’entendre que les salaires sont plus bas que pour les langages grand public
    Je me demande si tu cherches aux États-Unis ou dans une autre région
  • Les salaires ont tendance à être régulièrement plus élevés que pour les stacks grand public. C’est en partie parce que la plupart des recrutements Elixir visent des ingénieurs seniors

• Une bonne fonctionnalité de cette version est l’ajout de get_in/1 qui fonctionne avec les structs. Par exemple, on peut écrire get_in(struct.foo.bar)
  Si foo renvoie nil, cela ne provoque pas d’exception lors de l’accès à bar

  • C’était déjà possible dans les versions précédentes d’Elixir, mais la syntaxe était verbeuse
    Pour des niveaux qui n’étaient pas des maps ordinaires, il fallait utiliser Access.key comme ceci
    get_in(struct, [Access.key(:foo), :bar])

• C’était la dernière pièce qu’il me manquait. J’attends avec impatience la suite
  À part ça, selon mes critères, ce langage est fonctionnellement complet à 100 %

  • La dernière fois que j’ai regardé Elixir, il semblait y avoir un consensus disant qu’il fallait quand même faire de l’Erlang au final
    Est-ce toujours le cas aujourd’hui, ou bien n’est-il plus nécessaire de descendre jusqu’à Erlang ?