Dix ans de programmation à Erlang

J'ai rejoint la communauté d'Erlang il y a environ 10 ans, au milieu de la première phase de battage médiatique. On nous a dit qu'Erlang est l'avenir de la concurrence et de la concurrence. Les implémenter dans cette langue est le plus simple et le plus rapide, et vous bénéficiez toujours d'une distribution gratuite. À cette époque, l'avenir semblait incroyable. La machine virtuelle a récemment reçu le support SMP , mais pour vraiment utiliser tous les processeurs, vous avez dû exécuter plusieurs machines virtuelles sur le même ordinateur.

Je veux réfléchir sur la dernière décennie. Dans cet article, je parlerai des phases de battage médiatique concernant Erlang, de l' échelle des idées dans la langue et de son impact possible sur la distribution de la langue, des changements que j'ai subis au cours de ces 10 années. En conclusion, je partagerai mes réflexions sur ce qu'Erlang n'a pas encore apporté à la communauté des programmeurs dans son ensemble.

Phase de battage médiatique

Le cycle de battage médiatique comprend les phases du cycle de vie d'un produit ou d'une technologie. Il s'agit d'un concept marketing, non scientifique, mais qui aide souvent à décrire l'essence de ce qui se passe. Ce qui m'intéresse le plus, c'est la phase de battage médiatique , une sorte de ruée vers l'or qui couvre la communauté des programmeurs. Peut-être avez-vous rencontré cela plus d'une fois, et toutes ces phases sont liées à une application tueur que tout le monde se précipite pour utiliser.

Les exemples qui me viennent immédiatement à l'esprit sont Ruby on Rails, How to Build a Blog Engine in 15 minutes (la phrase «Regardez tout ce que je ne fais pas!» Est toujours drôle) ou Go with Kubernetes (ils ont travaillé ensemble avant cela, et puis il y a eu une poussée directe). Cela comprend Elixir et Phoenix.

Pendant la phase de battage médiatique, il y a un afflux incroyable de nouveaux arrivants qui veulent voir de quoi il s'agit. Il reste quelqu'un, la plupart partent. Vous pouvez rester pendant des mois ou des années, dans de rares cas, vous vous trouvez une maison pendant des décennies. Cependant, la grande majorité est un flux constant de personnes en série qui sautent de technologie en technologie, à la recherche d'occasions de bénéficier du fait qu'elles sont les premières à utiliser un cadre, un langage ou une boîte à outils.

Donc, le plus souvent, vous devez créer une véritable «application tueuse», et les gens entreront dans votre écosystème. L'application tueur stimule l'excitation. Si vous l'écrivez, ils viendront à vous. Et si vous pouvez en garder une petite fraction et les garder actifs, vous aurez une communauté dynamique dans un avenir prévisible. Cela rappelle un peu l'idée de la pluie après une charrue :

Le Seigneur conduit la charrue ... À la suite de cette merveilleuse adaptation, qui est la seule domination de l'homme sur la nature, les nuages ​​déversent de fortes pluies ... [la charrue] est un outil qui sépare la civilisation de la barbarie, il transforme le désert en fermes et jardins. ... Bref, la pluie suit la charrue.

L'essence de la théorie était que l'habitation humaine et l'agriculture ont un impact irréversible sur le climat des régions arides et semi-arides, rendant ces régions plus humides. Cette théorie s'est répandue dans les années 1870 pour justifier la colonisation des Grandes Plaines, une région anciennement connue sous le nom de Grand désert américain. Au cours de ces années, cette théorie a été utilisée pour justifier l'expansion des cultures de blé dans les terres marginales du sud de l'Australie.

Si nous pouvons lancer un grand projet, les développeurs apparaîtront et il deviendra autosuffisant. Je pense que cette idée est clairement erronée, principalement parce qu'Erlang a eu des dizaines d'applications tueuses pendant la plus grande phase de battage médiatique, mais la communauté est toujours petite. Voici des exemples de ces applications:

• ejabberd (2002, première version stable en 2005): c'était l'un des serveurs de chat les plus, sinon le plus évolutif. Ejabberd a connu un grand succès et, dans une certaine mesure, il est toujours d'actualité. Aujourd'hui, sur StackOverflow, il y a encore des questions sur les modules pour ce serveur. Vers 2011, il a été intégré à MongooseIM et les deux solutions sont toujours prises en charge.
  
• CouchDB (2005): l'une des bases de données les plus populaires écrites en Erlang, qui était basée sur le théorème CAP . Il fait référence à l'époque de l'émergence des référentiels multimaître. Bien que MongoDB ait pris la majeure partie du marché, CouchDB a des successeurs spirituels parmi les moteurs de stockage comme BarrelDB , qui est toujours pris en charge.
  
• RabbitMQ (2007): un serveur de mise en file d'attente de messages qui a écrasé la plupart du marché AMQP. Il développe et concurrence souvent Kafka en ce qui concerne les charges de streaming, bien que ces produits aient des capacités et des applications différentes.
  
• Chat Facebook (2008): La version initiale de Facebook Chat a été écrite en Erlang. Pour un certain nombre de raisons internes (stabilité, un grand nombre de programmeurs C ++ et un certain nombre de solutions établies), il a ensuite été réécrit en C ++.
  
• WhatsApp (2009, acheté en 2014): lorsque Facebook s'est débarrassé du système de chat Erlang, ils ont acheté WhatsApp, qui ne nécessitait que 50 ingénieurs pour 900 millions d'utilisateurs . Il vit à ce jour, et de plus, l'équipe WhatsApp a encore renforcé ses liens avec les communautés Erlang et Elixir.
  
• Riak (2009): L'un des meilleurs exemples de démonstration de puissance dans le monde des systèmes distribués. Riak était un stockage distribué fiable de type valeur-clé. Il s'agit d'un produit Basho qui fonctionne toujours dans les systèmes de soins de santé et d'autres éléments d'infrastructure critiques. Plus tard, Basho a fait faillite (dans une large mesure en raison de violations des obligations fiduciaires , qui "à pleine vitesse ont conduit l'entreprise à l'effondrement" ). Bet365 a ensuite acheté toutes ses adresses IP, les a généreusement ouvertes, et depuis lors, la base de données vit dans le monde de l'open source, bien qu'aujourd'hui elle traverse une période difficile.
  

Beaucoup de ces produits ont été lancés lors de la première édition du livre Programming Erlang de Joe Armstrong. En conséquence, une explosion de la popularité de la langue est survenue et Erlang a gagné beaucoup d'admirateurs. Un impact significatif a même été le fait que Hacker News a forcé toutes les discussions sur les entrailles d'Erlang . Cependant, peu sont restés fidèles à cette langue.

Maintenant, je crois que les applications tueuses sont créées par des personnes qui forment la phase initiale du battage médiatique, et non l'inverse. Il y a toujours une petite partie de personnes qui recherchent des technologies intéressantes avant les autres, décident si elles les aiment, puis créent quelque chose, et si vous obtenez une application killer, cela stimule le développement d'une phase de battage médiatique encore plus puissante. Les gens s'engageront dans le culte du fret et les projets réussis produiront des imitateurs. De plus, la situation standard est la phase de «l'invention de la roue», où chacun passe son temps à réinventer des choses existantes, et il y a une vague de messages sur «l'implémentation de X, mais en langage Y».

Cependant, il ne suffit pas de créer une application qui tue. Curieusement, tous ces produits, comme RabbitMQ et Ejabberd, malgré leur popularité, ont une communauté d'utilisateurs beaucoup plus importante que la communauté des développeurs. Des milliers et des milliers de sociétés utilisant ces produits n'apportent pas nécessairement une contribution significative à la communauté d'Erlang.

Cela est dû en partie au fait que la plupart des applications Erlang tueuses sont utilisées dans des infrastructures spécialisées. Vous avez créé un composant très fiable sous la forme d'une boîte noire que tout le monde utilise, et si cela fonctionne bien, personne ne regardera à l'intérieur. Plusieurs dizaines de développeurs ont jeté les bases de milliers d'autres produits et services. Par définition, une infrastructure spécialisée n'a pas besoin d'un grand nombre de personnes pour assurer son impact généralisé. Il a toujours peu de développeurs et une petite communauté par rapport aux technologies plus proches du produit final, par exemple, les frameworks web, ou même des infrastructures plus généralisées qui sont utilisées dans de petits projets de déploiement adaptés à toute entreprise.

Mais même avec tout cela, il est évident qu'Erlang a raté les nombreuses personnes qui l'ont traversé pendant la phase de battage médiatique.

Escalier d'idées

Je ne déclamerai pas ce qui aurait pu ou aurait dû être fait. Au lieu de cela, je veux parler des schémas d'apprentissage populaires que j'ai rencontrés dans la communauté Erlang au cours des années de mon enseignement et de la programmation de cette langue. J'observe les mêmes modèles aujourd'hui dans la communauté Elixir, et cela peut indiquer un avenir similaire pour lui.

J'ai une théorie selon laquelle un sujet technique comme un langage de programmation (et son écosystème) a plusieurs niveaux de complexité auxquels différents concepts sont situés. J'ai utilisé cette théorie dans le projet Learn You Some Erlang . Il est présenté dans le diagramme, que j'ai appelé les neuf cercles d'Earl .

Bien sûr, c'est une idée ironique, je ne pense pas que l'étude d'une technologie soit une souffrance sans fin (du moins elle ne devrait pas l'être). J'ai juste aimé le jeu de mots. En termes simples, il y a toujours une sorte de chemin ou de séquence «principale» de ceux que vous apprenez en étudiant la technologie - c'est «l'échelle des idées», et plus le concept est situé sur cette échelle, plus il est précieux et difficile à réaliser, moins il y a de personnes la connais.

À quoi pourrait ressembler l'escalier des idées à Erlang:

1. Programmation fonctionnelle.
   
2. Processus isolés et compétitivité.
   
3. Compétitivité fiable (liens, moniteurs, timeouts).
   
4. Principes OTP et autres abstractions du système.
   
5. Comment structurer les systèmes selon les principes de l'OTP.
   
6. Comment collecter les versions et travailler avec elles (déploiement).
   
7. Comment éviter un plantage du système et travailler avec.
   

Si vous venez de connaître Erlang et d'acheter un livre pour débutants, vous passerez probablement les premiers jours à la première étape de l'échelle: familiarisation avec la programmation fonctionnelle, immuabilité (immuabilité), récursivité et autres concepts similaires. Tôt ou tard, vous arriverez à la compétitivité et au parallélisme, aux processus et à la messagerie. Immédiatement après eux, vous commencerez à vous renseigner sur les liens et les moniteurs, à gérer les échecs et à savoir ce que fait Erlang. Pendant la grande phase de battage médiatique, les deuxième et troisième étapes contenaient des opportunités qui pour la plupart des observateurs semblaient tout simplement incroyables. Si vous aviez besoin d'apprendre quelque chose que vous utiliserez dans tous vos projets futurs, vous pouvez choisir l'une de ces fonctionnalités Erlang.

Vous pouvez passer à d'autres étapes plus tard, mais uniquement si vous adhérez au programme de formation étape par étape. En particulier, l'OTP (quatrième étape) peut être décrite comme «de quoi il s'agit». La compétitivité et la programmation fonctionnelle sont bonnes, mais le cadre global présenté avec OTP était vraiment unique et devait être utilisé. Au fil du temps, beaucoup travailleront avec lui, découvriront qu'ils peuvent créer des abstractions sympas, mais ils n'aimeront pas l'approche de la structuration.

En fait, pour créer des applications comme Ejabberd, il suffisait de surmonter la quatrième étape. À cette époque, l'écosystème ressemblait au Far West, et la connaissance d'OTP appartenait aux spécialistes travaillant chez Ericsson, ainsi qu'aux autodidactes les plus motivés. La plupart n'ont jamais atteint la cinquième étape, sauf s'ils ont envoyé quelque chose à la production et ont ensuite rencontré des problèmes, ou s'ils n'ont pas cherché une meilleure solution. La réalisation de la sixième étape était rare jusqu'en 2015-2016, puis Relx est apparu, ce qui a simplifié l'assemblage des versions et leur développement. Presque personne n'a atteint la septième étape, et beaucoup de gens pensent qu'ils ne devraient pas effectuer de mise à jour à chaud du nœud Erlang, et, idéalement, vous n'aurez jamais besoin d'utiliser SSH pour le débogage en production.

Dans la pratique, tout le monde ne monte pas l'échelle des idées dans le même ordre; ses étapes dans certains livres sont inversées (par exemple, dans Erlang et OTP in Action ). Il n'y a rien de mal à cela, l'escalier a été inventé juste à titre d'illustration.

La taille des communautés change par vagues. Pendant les phases de battage médiatique, la taille pendant un certain temps peut augmenter de dizaines ou de centaines de fois, et toutes ces personnes seront curieuses et partiront. La plupart des participants s'assoient sur la première marche des escaliers et la laissent rarement derrière eux. Certains atteignent la deuxième étape, encore moins la troisième, et ainsi de suite, jusqu'à ce que vous atteigniez un cercle restreint d'experts au plus haut niveau.

Je pense que gravir les trois premières marches d'Erlang a été facile. Pour grimper au quatrième, il a fallu se développer pendant plusieurs années, et en effet ressentir le besoin de poursuivre les études. À la cinquième étape, c'est déjà très difficile. La boîte à outils et l'écosystème d'Erlang étaient médiocres. Les membres de la communauté ont enduré cet environnement stérile et étaient indifférents au sort des nouveaux arrivants. Pour raccourcir l'article (enfin, long, mais pas absurdement long), voir mon exposé sur l'écosystème linguistique à la conférence des utilisateurs d'Erlang:


Si vous écrivez sur Elixir, vous voyez probablement à quelle étape de cet escalier confectionné vous vous tenez, et vous pouvez déjà imaginer dans quelles proportions la communauté est répartie dessus. De nombreux participants parlent couramment Phoenix seul, mais dépassent rarement la quatrième étape, et beaucoup sont coincés dans la troisième et plus bas. Et souvent cela suffit. Je ne blâme pas, mais partage seulement l'observation. Comme toute personne qui a franchi de nombreuses étapes (et il y a probablement plusieurs autres étapes devant moi, comme «patcher une machine virtuelle» ou autre chose), je vois que ces gens ne savent pas grand-chose. Mais honnêtement, toutes ces informations peuvent leur être inutiles. Et c'est bien.

Ce que je veux dire: je pense qu'en tant que communauté, nous scions probablement des chiennes sous nous, ce qui rend l'échelle des idées très difficile à maîtriser au-dessus du niveau de base. Certains sujets doivent être étudiés lentement, et dans certains sujets, les aveugles conduisent les aveugles car Erlang est si petit que nous avons juste trop peu de gens qui peuvent partager toute l'expérience nécessaire. Aujourd'hui, c'est plus simple, et si vous n'êtes pas venu à Erlang pendant la phase de battage médiatique, vous obtiendrez probablement de l'aide, car beaucoup moins de personnes le demandent en même temps.

J'aimerais penser que si la deuxième phase de battage médiatique commence dans le monde d'Erlang demain, alors nous serons en mesure d'accepter les nouveaux arrivants mieux que pendant la grande vague, quand je suis venu. Et j'espère que cette expérience, couplée à une collaboration plus étroite entre les communautés d'Erlang et d'Elixir, doublera nos chances d'élargir avec succès l'utilisation de ces langues.

Ce qui a changé

Erlang ne nage pas dans le ballon, attendant qu'il soit tiré dans la lumière. Il évolue constamment. Cela est dû en partie à la concurrence et aux suggestions de la communauté Elixir, qui, heureusement, attend beaucoup plus de ses outils que ce à quoi les utilisateurs d'Erlang sont habitués. Et en partie, le développement est déterminé par les besoins urgents de l'industrie et les souhaits de la communauté universitaire.

Je pense que quelqu'un sera satisfait de ces changements survenus depuis 2009 ou même plus tôt:

• Le support multicœur fonctionne désormais bien. Auparavant, s'il y avait plus de 2 à 4 cœurs, le système reposait sur toutes sortes de goulots d'étranglement qui n'étaient pas soumis au développeur de l'application. Ensuite, il est devenu possible d'utiliser 12-16 cœurs. Aujourd'hui, je ne sais même pas quelle est la limite supérieure, mais j'ai écrit et géré des piles qui fonctionnaient sur plus de 32 cœurs sans aucun problème.
  
• Les traces de pile ont maintenant des numéros de ligne. Il est presque impensable de revenir dans le passé, avant que les chiffres n'apparaissent. A cette époque, «écrire de courtes fonctions auto-documentées» n'était pas une question d'architecture, mais de survie. Vous pouvez désormais déboguer les programmes Erlang sans compétences de débogage surnaturelles, bien qu'ils ne soient jamais nuisibles.
  
• La qualité du support Unicode est actuellement acceptable. Le module de chaînes contient les algorithmes les plus importants et le module unicode fait un excellent travail avec la plupart des types de transformations et de normalisations. Il existe des approches typiques pour travailler avec des points de code, UTF-8, UTF-16 et UTF-32. Le support local laisse encore beaucoup à désirer, mais tout le reste est opérationnel. Les modules tels que re (un module pour travailler avec des expressions régulières) et toutes les fonctions de haut niveau pour travailler avec des fichiers n'ont également aucun problème lorsque vous travaillez avec Unicode.
  
• Les cartes (implémentées en tant que HAMT ) avec une syntaxe de correspondance de modèle explicite sont prises en charge . À l'aide de l'analyse de type Dialyzer, elles sont appliquées, ce qui leur permet d'être utilisées dans les cas où l'utilisation des enregistrements nécessitait auparavant beaucoup d'efforts.
  
• Les machines virtuelles utilisent désormais d'excellents mécanismes pour travailler avec le temps , elles font face à un changement dans l'échelle de temps, différents types d'horloges et plus encore. Cependant, il est préférable de travailler avec les fuseaux horaires et de formater l'heure avec l'aide des bibliothèques développées par la communauté.
  
• Des outils hautes performances tels que atomiques , compteurs et termes persistants ont été ajoutés pour aider à améliorer les différents mécanismes sous-jacents aux outils de surveillance et aux bibliothèques de base de bas niveau.
  
• Tout le traitement du signal est devenu asynchrone , y compris le travail avec les ports , ce qui nous a évité de nombreux goulots d'étranglement.
  
• Le compilateur a été réécrit et est toujours en cours de réécriture pour améliorer l'analyse de haut niveau et les performances à l'aide de SSA.
  
• Il y avait un type spécial d'ordonnanceurs à utiliser dans NIF - les ordonnanceurs sales, qui simplifiaient l'intégration avec du code écrit en c ou même rust, prenant en charge à la fois les processus gourmands en CPU et en E / S. Ainsi, bien que le langage lui-même ne soit pas devenu beaucoup plus rapide (bien qu'il y ait des progrès), il est devenu beaucoup plus facile de connecter des bibliothèques hautes performances sans affecter indûment la stabilité de la machine virtuelle.
  
• Diverses améliorations ont été apportées au mécanisme d'allocation et de gestion de la mémoire.
  
• L'analyse du programme est devenue plus précise et plus rapide grâce à un traçage et une comptabilité plus rapides et plus flexibles des microstats .
  
• Le comportement OTP plus flexible de gen_statem a permis l'implémentation de machines à états finis qui peuvent traiter les données d'entrée de manière sélective.
  
• Infrastructure de journalisation nouvelle et améliorée avec prise en charge intégrée des journaux structurés.
  
• Le module de chiffrement est réécrit et utilise NIF au lieu des pilotes plus complexes (et souvent plus lents à jour).
  
• Le pilote de fichier a été complètement réécrit à l'aide de NIF, ce qui a considérablement amélioré les performances.
  
• Pour obtenir les mêmes performances, ils continuent de réécrire les pilotes réseau à l'aide de NIF.
  
• Refonte complète de l'utilisation de SSL pour le traitement TLS. Lorsque j'ai travaillé chez Heroku, nous avons essayé de rendre le produit comparable aux solutions C ++ en termes de retard (peut-être 5% pire) et de dépassement significatif en termes de prévisibilité (10-30 fois moins que 99 centiles).
  
• Performances ETS considérablement améliorées.
  
• J'ai écrit un guide sur la gestion et le débogage des systèmes de production sur les machines virtuelles Erlang.
  
• Un tout nouvel outil de construction ( rebar3 ), intégré au gestionnaire de packages unifié pour l'écosystème Erlang.
  
• , . Elixir, Efene, LFE, Luerl, Clojerl Gleam Alpaca.
  
• Erlang.
  

, . , OTP Ericsson 13-16 ( 22!), Erlang . , Ericsson. Erlang Elixir, Erlang VM , Erlang Ecosystem Foundation , , , (observability — ), , ..

, , , , , , , , , Erlang . .

Erlang

, , 2007-2009, , . Erlang , . , , BEAM Conf. (Property-Based Testing), Erlang Elixir . , . , .

? , , , . , Elixir. , , , . , . , . . , . Erlang, , .

, Erlang . , , Erlang-, Erlang-: , , . , .

Erlang -, Elixir-.

, , Erlang . , . Erlang , . , .

, . ? ? , - ? , , ? ? , ? « - »?

, , « ». , Erlang . , . junior senior-, , , , .

, 15 ( , ), . , et leur création et leur mise en condition de travail. Chacun a sa propre motivation.

Je ne peux pas imaginer que je gagnerais autant dans une autre communauté. Ces 10 années ont été incroyables. Il est curieux que la communauté d'Erlang soit encore petite et que son potentiel ne soit pas révélé. Cela signifie qu'il existe de nombreuses opportunités de participer à tout, de communiquer face à face avec des gens pleins de sagesse et qui veulent la partager, et trouver leur place.

PS. Merci d'avoir traduit mail ru group; Communauté d'Erlang dans Telegram (Evgeny M., Sergey Ivanov, Vladimir Sekisov, Greg)