L’essentiel d’Erlang ne réside pas dans les processus légers ni dans le passage de messages (2023)

Contexte

• Erlang est un langage développé pour construire des systèmes distribués fiables. Il a d’abord commencé comme une bibliothèque Prolog avant d’évoluer en langage indépendant.
• Il a été utilisé chez Ericsson pour programmer des centraux téléphoniques, puis est passé en open source en 1998.
• Joe Armstrong est l’un des principaux concepteurs d’Erlang, et sa thèse de doctorat portait sur la manière de construire des systèmes distribués fiables en présence de bugs logiciels.

Behaviours

• Les behaviours d’Erlang sont similaires aux interfaces en Java ou en Go : ce sont des ensembles de signatures de types pouvant avoir plusieurs implémentations.
• Avec les behaviours, il suffit d’écrire le code qui définit la logique métier du programme, tandis que le code d’infrastructure est fourni automatiquement.
• Les behaviours sont écrits par des experts et reposent sur les meilleures pratiques.

Behaviour de serveur générique

• gen_server est présenté à travers l’exemple de l’implémentation d’un magasin clé-valeur.
• handle_call sert à mettre à jour l’état ou à consulter une clé, et toute la concurrence est masquée dans le composant gen_server.

Behaviour de gestionnaire d’événements

• gen_event est un gestionnaire d’événements qui enregistre des handlers et les exécute lorsqu’un message arrive.
• Il est utile pour la journalisation des erreurs, avec un exemple simple de logger.

Behaviour de machine à états

• gen_fsm a été renommé en gen_statem et convient bien à l’implémentation de protocoles.

Behaviour de superviseur

• Un superviseur vérifie que les autres processus fonctionnent correctement et, en cas d’échec, les redémarre selon une stratégie prédéfinie.
• La stratégie one_for_one ne redémarre que le processus en échec, tandis que la stratégie one_for_all redémarre tous les enfants si un seul processus échoue.

Behaviour d’application et de release

• Une application comprend l’arbre de supervision et tout le nécessaire, tandis qu’une release empaquette une ou plusieurs applications.
• Il faut pouvoir revenir en arrière en cas d’échec d’une mise à niveau.

Implémentation des behaviours

• Plus que les processus légers et le passage de messages d’Erlang, c’est la structure des behaviours qui mène à des logiciels fiables.
• Pour implémenter des behaviours dans d’autres langages, on peut commencer par utiliser des signatures d’interfaces.

Correction des behaviours

• Les tests de simulation facilitent les tests des systèmes distribués, et la structure du behaviour gen_server peut simplifier la résolution de problèmes.

Contribution

• Parmi les idées proposées : reprendre des idées du travail de Martin Thompson pour créer une boucle d’événements rapide, ajouter des E/S asynchrones, etc.
• Toute personne intéressée, ou ayant des avis, suggestions ou questions, peut prendre contact.

[GN⁺]

Commentaires sur Hacker News

• Ce qui est remarquable avec Erlang et BEAM, c’est la profondeur de leurs fonctionnalités. Pour l’OP, la plus grande découverte a été les behaviors/interfaces d’Erlang. Personnellement, je pense qu’il est important que les ressources de développement nécessaires pour construire des systèmes complexes soient bien moindres que dans d’autres langages. Pour beaucoup, ce sont les processus légers et le modèle de programmation qui sont attrayants

  • OTP inclut énormément de fonctionnalités. Nous travaillons actuellement à compiler Elixir pour qu’il puisse s’exécuter sur des appareils iOS. En utilisant la bibliothèque ei d’Erlang, il est possible de compiler des nœuds en C et d’interfacer avec d’autres nœuds Erlang. La bibliothèque rpc d’Erlang permet d’appeler des fonctions depuis C et d’interagir avec des applications Elixir
  • Erlang a résolu de nombreux problèmes avec lesquels les stacks technologiques modernes peinent encore, et a réglé les questions de scalabilité et de coût d’implémentation il y a plusieurs décennies. Pourtant, sur HN, l’intérêt pour Erlang/Elixir ne s’est pas traduit par une adoption réelle, et beaucoup d’entreprises gaspillent de l’argent à implémenter ce que la stack Erlang fournit gratuitement

• J’ai travaillé avec plusieurs managers et des personnes qui voulaient écrire un livre à partir de leur expérience. Nous étions toujours en désaccord sur les facteurs de réussite. Certains affirment que les processus légers et le passage de messages ne sont pas la sauce secrète, mais ils passent à côté du fait que les Communicating Sequential Processes d’Erlang sont indissociables de ces caractéristiques

  • Exemple : les programmeurs applicatifs écrivent du code séquentiel, et toute la concurrence est masquée dans les behaviors
  • Il est facile pour un nouveau membre de l’équipe de démarrer : la logique métier est séquentielle et ressemble à des structures analogues qu’il a peut-être déjà vues
  • Les superviseurs et la philosophie « laisser crasher » contribuent à la création de systèmes fiables

• Ce sont les processus légers et le passage de messages qui m’ont redonné de l’intérêt pour Erlang. Jusqu’à présent, les behaviors étaient secondaires

  • Le projet consiste à introduire le Flow Based Programming (FBP) visuel dans Erlang. Le FBP semble bien convenir à Erlang, et j’ai été surpris de voir que cela existait déjà
  • J’utilise Node-RED comme outil pour le FBP, et l’idée de base est de connecter le frontend de Node-RED à un backend Erlang et de faire de chaque nœud un processus

• Je cherchais des informations sur les raisons pour lesquelles Ericsson avait cessé d’utiliser Erlang, ainsi que sur le licenciement de Joe

  • La réponse courte, c’est qu’Erlang a été marginalisé au moment du passage à Java pour les nouveaux projets. Joe et ses collègues ont fondé Bluetail en 1998, qui a ensuite été racheté par Nortel. Nortel était un géant des télécoms dont l’action avait atteint 125 $ en 2000, avant de tomber sous 1 $ en 2002. Cela était lié à l’éclatement de la bulle internet et à la baisse des dépenses dans les télécoms

• La force d’Erlang/Elixir ne réside ni dans l’implémentation du modèle Acteur, ni dans le matching de Prolog, ni dans l’immuabilité, ni dans les behaviors, mais dans le désir de Joe de montrer qu’on peut faire plus avec moins de ressources

  • C’est un système cohérent et bien conçu, avec une homogénéité rarement observée dans d’autres langages. Ce n’est pas parfait, mais c’est impressionnant
  • Je pense qu’il y a un manque de reconnaissance et d’acceptation du pouvoir de la simplicité dans le monde du logiciel

• Erlang, OTP et BEAM offrent bien plus que des behaviors. La VM ressemble à un noyau virtuel et fournit des superviseurs, des processus isolés et un mode distribué. OTP propose aussi des modules utiles comme Mnesia (base de données), les compteurs atomiques / tables ETS (cache), etc.

  • Il y a un an, j’ai adopté Erlang comme langage backend dans mon activité de conseil individuelle. J’ai exploré l’intérieur de BEAM pour remplacer une stack basée sur TCP par QUIC et intégrer des patchs Rust

• Le concept le plus intéressant dans Erlang/BEAM est que la récupération partielle est intégrée par défaut. Lorsqu’un état inattendu se produit, au lieu de terminer le processus entier ou de risquer une corruption, on revient au dernier bon état connu au niveau le plus fin possible

• Si d’autres langages et concepteurs de bibliothèques ne reprennent pas la structure des behaviors d’Erlang, c’est parce que la signature de leurs fonctions est étroitement liée à d’autres caractéristiques d’Erlang, en particulier son usage particulier de l’immuabilité

  • Pour atteindre le même objectif dans d’autres langages, il ne faut pas copier directement l’approche d’Erlang. Je recommande d’apprendre de la manière dont Erlang conçoit des logiciels fiables, mais je déconseille fortement de porter tel quel l’approche d’Erlang dans d’autres langages

• Je ne suis pas d’accord avec le contenu de cet article. Les behaviors sont rendus possibles par l’architecture fondamentale du système. Les behaviors ne sont pas des interfaces, mais sont plus proches des objets abstraits dans des langages comme Java

  • L’article de Joe montre comment construire des systèmes fiables à partir d’un ensemble donné de briques Lego

• Les behaviors ne sont pas si intéressants. On en trouve aussi dans d’autres langages de programmation. Ce qui est intéressant dans BEAM, c’est l’élégance avec laquelle on peut lever des erreurs. Le fait de lever des erreurs, combiné à la puissance des behaviors, facilite la capture des erreurs, le reporting d’informations de contexte et rend l’ensemble globalement composable