Mon programme Erlang préféré (2013)

 (joearms.github.io)
2 points par GN⁺ 2023-09-09 | 1 commentaires | Partager sur WhatsApp
  • Avec la seule plage de notes fournie, il est impossible de déterminer ce qu’est le programme Erlang du titre ni pourquoi il est important
  • Le texte vérifiable se limite surtout à des fragments de script Shell et à une courte phrase de correction
  • Le script parcourt les fichiers *.png.png.meta du répertoire courant et extrait de leur nom la partie située avant le premier point
  • La commande réellement exécutée est git mv $i $j.png.meta, tandis que la commande qui remplacerait $j.png.png par $j.png est seulement affichée
  • Comme les chunks originaux 5-104 sont omis, il est impossible de vérifier l’argument central lié au titre ou toute explication du code Erlang

Contenu vérifiable

  • Avec la seule plage fournie, il est difficile d’identifier ce qu’est le « programme Erlang préféré », pourquoi il est apprécié ou quelle est sa structure
  • Le fragment de code vérifiable est un script Shell de renommage de fichiers commençant par #!/bin/sh
    • Il boucle sur les fichiers *.png.png.meta
    • j="${i%%.*}" extrait du nom de fichier la partie avant le premier point
    • git mv $i $j.png.meta est réellement exécuté
    • git mv $j.png.png $j.png n’est qu’affiché via echo
  • La phrase « Actually you don't need the really do this. It should have been water the plants. » apparaît et peut être lue comme une correction indiquant que l’instruction ou l’exemple précédent n’était en réalité pas nécessaire et qu’il aurait fallu écrire « water the plants »
  • À la fin, Joe Armstrong et Jeremy Ruston sont mentionnés ensemble

Contexte qui limite l’analyse

  • Plusieurs chunks se composent de métadonnées d’état/barre latérale TiddlyWiki, de données Base64 ressemblant à du JPEG/PNG, ou de contenu vide, ce qui rend l’extraction des faits du corps du texte difficile
  • Les notes fournies ne contiennent pas les informations essentielles sur le fonctionnement du programme Erlang, son code, ses raisons de conception, ses exemples, ses chiffres, son workflow ou ses thèses
  • Même le fragment de script Shell n’est fourni qu’en partie et sans explication contextuelle, ce qui empêche de déterminer avec certitude à quelle tâche il appartient

Plage omise

  • L’entrée indique explicitement que les chunks originaux 5-104 ont été omis en raison de limites de longueur/coût
  • Ce résumé reflète uniquement la plage de notes fournie et ne couvre ni les détails ni la conclusion du texte complet

À lire aussi

1 commentaires

 
GN⁺ 2023-09-09
Commentaires Hacker News

  • Si la closure serveur F peut recevoir, en plus de ses propres messages, un message {become, F}, alors on peut continuer à transformer le serveur en de nouveaux comportements
    Rien à voir, mais je garde le souvenir d’une conversation avec Joe lors d’une conférence Erlang. Il était toujours enthousiaste à propos de la technologie et prêt à parler avec n’importe qui. Il regrettait que Windows devienne chaque année pire et moins utilisable, et disait qu’un jour, pour consulter un fichier, il faudrait regarder des publicités pendant un moment avant qu’il ne soit déverrouillé ; il n’était pas loin. Windows 11 contient déjà des pubs, et il faut aller délibérément fouiller dans les paramètres pour les supprimer, donc vers Windows 13 cela pourrait vraiment se produire

    • À la maison j’utilise Linux et au travail Windows, et ce qui m’a plus surpris que les publicités, c’est que sous Windows je vois beaucoup plus souvent des problèmes étranges qu’on ne rencontrait autrefois que sous Linux
      Le son beaucoup plus fort dans un seul écouteur, des applis Microsoft qui plantent bizarrement, des pages de documentation Windows qui ne s’ouvrent dans aucun navigateur et obligent à utiliser un site d’archive, un écran externe auparavant bien détecté qui ne l’est soudainement plus, ou un écran qui clignote. Office pousse par défaut à enregistrer dans le cloud plutôt qu’en local, alors que je préférerais que les fichiers soient local first et que le cloud serve de sauvegarde. WSL est assez bancal, mais c’est à peu près la seule raison qui rend encore Windows utilisable
      J’ai toujours entendu dire que Joe était quelqu’un de formidable, et je le comprends. Quand j’ai appris à coder en autodidacte, j’ai lu son livre sur Erlang, et son côté joueur, son humilité et son imagination m’ont beaucoup marqué. Je n’ai presque jamais fini par utiliser Erlang, mais ses écrits ont changé ma façon de penser le code, et j’aimerais que les cultures des maths, du génie logiciel et de l’informatique accueillent davantage l’esprit joueur et l’humilité
    • Ce qui est décrit dans le premier paragraphe est en fait une fonctionnalité du modèle d’acteurs. Je ne savais pas auparavant que c’était aussi possible dans BEAM
    • Les publicités intrusives de Windows 11 ne sont pas nouvelles. Il y en a déjà dans Windows 10

  • Une courte vidéo de présentation de 35 minutes expliquant en quoi BEAM diffère d’autres machines virtuelles comme la JVM ou Node : https://www.youtube.com/watch?v=pO4_Wlq8JeI

    • J’ai vu une présentation similaire, The Soul of Erlang and Elixir, elle était vraiment excellente et elle me redonne envie à chaque visionnage

  • Joe me manque. Sa passion contagieuse pour rendre l’informatique meilleure a profondément marqué le jeune que j’étais et ma manière actuelle d’aborder la technologie

  • universal_server() -> receive {become, F} -> F() end.
    Honnêtement, je ne comprends pas complètement la puissance de ce universal_server. J’aimerais que quelqu’un me l’explique

    • Si vous connaissez Go, c’est similaire à une goroutine qui attend que quelqu’un lui envoie une fonction anonyme à exécuter
      En Erlang, on lance beaucoup de processus pour résoudre un problème, et la plupart attendent des messages. La différence importante est qu’un processus Erlang peut aussi s’exécuter de façon transparente sur une machine distante. Ce processus reçoit un message sous forme de tuple contenant l’atome become et une fonction, et lorsqu’un autre processus lui envoie ce message, il « devient » cette fonction
      Autrement dit, on peut remplacer la logique de la boucle d’attente par la logique de protocole que l’on veut. Dans l’exemple, on lance cette boucle sur plusieurs machines et on lui envoie une fonction implémentant un protocole de gossip, mais on pourrait tout aussi bien envoyer un message qui en fait un client BitTorrent. Joe était un génie et quelqu’un de très bienveillant, et Erlang est l’une des créations techniques les plus belles que j’aie vues. Cela fait voir la concurrence d’une manière complètement nouvelle
    • Pour détailler un peu, le mot-clé receive ressemble à un switch sur les messages entrants, mais c’est en réalité du pattern matching
      Par exemple, on peut créer un serveur de factorielle qui reçoit {From, N} et renvoie le résultat avec From ! factorial(N). ! est l’opérateur qui envoie le résultat au processus de retour
      Le code de test lance universal_server, le transforme en serveur de factorielle avec Pid ! {become, fun factorial_server/0}, puis envoie {self(), 50} pour récupérer la factorielle de 50. Les grands atouts d’Erlang sont le parallélisme distribué et les mises à jour de code à chaud, et ici cela se manifeste comme le remplacement de la boucle de réception de universal_server par celle de factorial_server. Cela dit, je ne pense pas que les vraies mises à jour de code à chaud fonctionnent exactement de cette façon
    • D’ordinaire, il faut savoir à l’avance à quoi servira un serveur et écrire le code en conséquence
      Mais avec Erlang, on peut créer un réseau distribué de serveurs Erlang et laisser les serveurs comme des ressources de calcul génériques capables d’exécuter ce que le client souhaite. Le code vient du client : au lieu de demander à un administrateur système d’installer un binaire sur toutes les machines, on transmet une fonction et la machine distante l’appelle
    • L’idée centrale est qu’il peut devenir n’importe quel type de serveur souhaité
      La fonction réelle qui exécutera le serveur est transmise par le client, et le processus Erlang devient ce serveur à partir de cette fonction. Si l’on tient compte des capacités de hot reloading d’Erlang, cette structure simple devient encore plus puissante. Un processus Erlang est une ressource de calcul qui attend du travail, et si ce travail consiste à exécuter un serveur complet, c’est plutôt élégant
    • La structure d’Erlang est particulière : la machine virtuelle comme le langage sont construits autour de l’idée que de petits processus fonctionnent simultanément et que chacun attend dans une boucle infinie pour interpréter les messages entrants
      Un processus peut donc devenir n’importe quoi selon le code qu’on lui envoie. Si vous devez contrôler un four à micro-ondes, puis effectuer du calcul quantique, puis prédire le vainqueur d’un match de football le lendemain, il suffit d’envoyer le code nécessaire à chaque tâche et il l’exécute

  • Je passe beaucoup de temps à expliquer pourquoi BEAM est spécial, et pourquoi la concurrence d’Erlang/Elixir, entre autres, diffère de celle de Go ou Java
    À partir de maintenant, je pense qu’il suffira de mettre un lien vers le programme Erlang préféré de Joe et vers ce fil HN

  • Ce billet de blog a aussi été abordé dans une excellente présentation récente : https://youtu.be/pQ0CvjAJXz4

    • C’est une présentation qui couvre et explique très bien chaque étape de l’architecture de systèmes Erlang distribués à haute disponibilité et tolérants aux pannes
    • Je me demande si c’est le système où chaque patient est représenté par un processus Erlang

  • Je n’ai qu’une compréhension de haut niveau d’Erlang et je n’ai jamais vraiment programmé avec, donc je me demande pourquoi ce code est nécessaire
    universal_server() -> receive {become, F} -> F() end.
    J’aurais tendance à penser qu’il suffirait de lancer directement F() sur la machine distante. Comme le code de F doit déjà être présent sur la machine virtuelle distante, cet exemple veut peut-être dire que le code de F est sérialisé et transmis. Si cela sert à gérer du boilerplate commun, j’en comprends l’utilité, mais pour l’instant cela ressemble à un processus qui attend un message become F puis exécute F()

    • Ce code est élégant, mais il n’est peut-être pas très idiomatique ni fréquent dans du code de production réel. Cela dit, Joe aimait explorer et expérimenter
      Ici, F est une fermeture : elle peut donc contenir non seulement du code, mais aussi les variables capturées et l’environnement au moment de sa création. Quand on appelle F(), ce code s’exécute et peut accéder au contexte environnant qui existait lorsque F a été créée
      En Erlang, on peut envoyer des fermetures à un autre nœud Erlang via le réseau. En revanche, le code des modules référencés par la fermeture doit être présent sur tous les nœuds. Dans du code de production, comme vous le dites, on appellerait plus probablement directement le module de F en passant explicitement les arguments ; ici, c’est plutôt une belle démonstration de ce qui est possible
    • C’est élégant parce que, grâce à la conception fonctionnelle d’Erlang, F() peut devenir un contexte de premier niveau tout aussi valable que n’importe quel contexte précédent
      On peut ainsi laisser les requêtes existantes être traitées naturellement par l’ancienne logique, tandis que les nouvelles démarrent avec la nouvelle logique, et l’ancienne logique finira par être collectée par le garbage collector
    • Il est vrai que le code de F doit déjà être présent sur la machine virtuelle distante, mais on peut aussi envoyer du code à cette machine virtuelle
      Par exemple, en Elixir, Code.compile_string permet d’obtenir un nom de module et un binaire de bytecode BEAM. On peut envoyer ce bytecode à une autre machine virtuelle, le charger sur la machine virtuelle distante avec :rpc.call('node@remote_host', :code, :load_binary, [the_module_name, "filename_doesnt_really_matter", binary_code]), puis le lancer avec spawn('node@remote_host', my_module, my_function, [args])
    • Le programme cité est conçu pour être exécuté sur une machine distante, qui désérialise le nouveau programme à exécuter
      Ici, F est une variable représentant le nouveau programme sérialisé et envoyé sous forme de message entre processus ; dans ce cas, il est aussi transmis via le réseau

  • Il existe aussi un cours où Joe explique comment écrire un serveur de base en Erlang : https://gioorgi.com/2015/erlang-lesson1/
    Je l’ai transcrit et un peu davantage expliqué ; cela montre la puissance des langages asynchrones comme Erlang/Elixir par rapport aux autres langages. Malheureusement, ils ne sont plus beaucoup utilisés aujourd’hui

  • Ces derniers temps, je me suis pris de passion pour Julia, et son modèle distribué semble pas mal emprunter aux idées d’Erlang
    On peut assez facilement reproduire dans Julia ce genre de serveur improvisé qui fonctionne comme par magie sur plusieurs nœuds. Je n’en suis pas certain, mais il me semble difficile d’imaginer que le module Distributed de Julia n’ait pas été inspiré, au moins un peu, par Erlang
    J’aime vraiment Erlang et j’aimerais avoir davantage d’occasions de l’utiliser, mais c’est aussi agréable de voir ses concepts infuser dans d’autres plateformes

    • Dans la communauté Julia, j’imagine qu’on serait du même côté pour défendre des leçons issues de la philosophie d’Erlang en matière de reporting d’erreurs, comme let it crash