La communauté Gandi Le lab des experts
Gandi était à la Rustconf 2019 !
par Arthur
Le 23 août dernier, à Portland, j’ai eu la chance d’assister à la Rustconf, une conférence dédiée aux développeurs Rust du monde entier. Rust est un langage de programmation récent qui met l’accent sur la programmation de bas niveau, la performance et offre des avantages de sécurité.
Chez Gandi, nous exploitons Rust en production depuis plus de 3 ans maintenant. Chaque fois que nos serveurs répondent à des requêtes DNS, par exemple, ils utilisent du Rust.
Lors de la Rustconf, j’ai assisté à plusieurs présentations données par des développeurs de Rust et des personnes travaillant à l’amélioration de Rust. Un thème commun aux discussions et à la conférence dans son ensemble a été l’importance de la communauté Rust et la nécessité de faire en sorte que cette communauté soit un espace accueillant pour les personnes de toute identité, où les gens sont amicaux et prêts à aider.
Mon expérience avec Rust a été une des meilleures. Bien que le langage ne soit pas facile à apprendre, car il change beaucoup les paradigmes habituels, la communauté qui gravite autour compense cette difficulté. Tout en essayant d’apprendre Rust, j’ai expérimenté l’accueil des canaux IRC avec multitude de personnes expérimentées prêtes à partager leurs connaissances, à aider à résoudre des problèmes ou à expliquer davantage les concepts.
Et d’après ce que j’ai pu entendre de la part des conférenciers et d’autres personnes que j’ai rencontrées lors de la Rustconf, c’est un sentiment partagé.
Keynote d’ouverture
La keynote d’ouverture a été prononcée par deux vétérans de la communauté, Steve Klabnik et Florian Gilcher, tous deux anciens développeurs Ruby impliqués dans la communauté depuis 2012. Ils nous ont fait parcourir l‘histoire du langage Rust et des essais de syntaxes que je n’avais jamais vus. Ils sont également revenus sur les récents changements survenus dans le langage Rust (syntaxe édition-2018) et les changements importants (async/await) encore à venir.
Après quelques années de travail, Rust s’est finalement mis d’accord sur une syntaxe stable pour décrire le comportement asynchrone. Cette syntaxe est importante pour Rust parce que le borrow-checker ne savait pas jusqu’alors comment gérer ces concepts et se mettrait en travers de son chemin. Pour contourner ces limitations, Rust nécessitait auparavant des syntaxes plus lourdes, et parfois des verrous logiciels qui rendaient plus difficile le développement d’un programme asynchrone dans Rust. C’est certainement le changement le plus excitant qui s’annonce pour Rust (attendu pour 1.39, en octobre, selon le calendrier de sortie).
Steve et Florian, deux principaux développeurs et observateurs de la core-team de Rust, ont expliqué comment ils s’appuient sur les commentaires de la communauté par le biais de groupes de travail, de blogs et de discussions informelles. Et ils ont décrit comment ces feedbacks leur sont particulièrement utiles pour décider comment façonner l’avenir de la langue.
Parce que le langage Rust est toujours en pleine croissance, il fait également face à de nouveaux défis, certains sont légaux (crates.io), mais la plupart sont d’ordre organisationnel. L’équipe va multiplier le nombre de groupes de travail, essayer d’intégrer plus de personnes, mais aussi de nouveaux modèles organisationnels orbit.
Un groupe de travail Rust-embedded arrive bientôt et c’est certainement un domaine dans lequel j’aimerais que Rust soit davantage utilisé.
Je pense que le message général du discours d’ouverture était de montrer que l’équipe de base se soucie beaucoup de la qualité, qu’elle n’a pas l’intention de précipiter la mise en production de fonctionnalités et qu’elle a besoin de beaucoup de feedback pour réaliser ce travail.
Class Fixes
La session suivante à laquelle j’ai assisté s’intitulait « Class fixes ; or, you become the Rust compiler » par Isobel Redelmeier.
En tant que développeur, vous pouvez rencontrer trois types de bugs : les erreurs logiques, les erreurs d’exécution et les erreurs de compilation. Isobel a montré comment utiliser le compilateur Rust et le système de type pour transformer les deux premières catégories de bugs en le troisième type. Ces erreurs de compilation sont le cas le plus souhaitable parce que, si elles se présentent, votre programme ne compilera pas, et vous rencontreriez alors ces bugs pendant la phase de développement, et non plus tard quand votre programme est déjà déployé en production avec des données sensibles.
Un exemple d’erreur d’exécution est l’infâme null-pointer exception de Java. Ce type de bug se produit parce que vous passeriez un pointeur nul au lieu de données, et Java demande à un développeur de vérifier l’entrée avant d’agir sur elle. L’utilisation d’un système de type et de la monadique Option peut aider un développeur à déclarer son intention et rustc s’assurera que le null est pris en compte.
Pour reprendre les termes d’un ancien collègue : « Un compilateur se fera un plaisir de prendre n’importe quelle séquence d’instructions, et de les transformer en code machine. Un système de type n’est pas utile à un ordinateur. C’est un outil pour aider un développeur à déclarer son intention et permettre au compilateur de vérifier que l’intention est bien conservée. »
Je pense qu’Isobel serait d’accord.
Syscalls
L’intervention suivante était celle de Gargi Sharma pour Syscalls for rustaceans. Parce que Rust est un langage orienté programmation système, Gargi nous a expliqué comment les systèmes ont été divisés pour réduire la taille et la complexité, et comment les syscalls sont utilisés à cette fin.
Chaque fois qu’un programme a besoin de déclencher un syscall, il configure les registres, puis va faire un context-switch dans le noyau qui sera routé par le système d’exploitation sur la fonction responsable du syscall. Le système d’exploitation fera son travail, puis reviendra au programme.
Gargi nous a guidés à travers les sous-systèmes strace et ptrace, et nous a montré comment tirer parti des programmes Rust.
Tracing
Ensuite, il était temps d’entendre Eliza Weisman parler de son projet tracing. Tracing est un cadre d’instrumentation qui fait le pont entre les logs et les cadres de traçage distribués (Zipkin, Jaeger….).
Nous avons besoin d’un tel cadre parce que la collecte de logs ne suffit pas lorsque nous essayons de débuguer des problèmes dans du code asynchrone. Avoir un flux continu de logs avec peu ou pas de lien entre eux n’est d’aucune aide pour un développeur pour trouver des bugs. Nous devons recueillir le contexte et la causalité, et fournir une certaine structure. Tracing est une solution élégante pour cela.
Il est exposé en remplacement de la crate log mais fournit également des API de type span (traçage distribué) qui vous permettent de regrouper et de contextualiser les données de sortie.
Eliza a fait une démo d’un serveur web à moyen trafic et a démontré comment elle pouvait utiliser l’écosystème de traçage pour reconfigurer la collecte des logs en direct, et ajouter un filtre basé sur les paramètres de demande pour mettre en évidence les problèmes et limiter le bruit.
C’est un projet très prometteur, j’aime particulièrement le fait qu’il offre une interface simple de type log qui le rend facile à déployer, et permet d’ajouter du contexte de facon incrémentale. C’est une solution élégante à un problème très complexe. J’ai hâte qu’un plus grand nombre de développeurs adoptent cet écosystème (et c’est surtout gratuit du point de vue des performances), et j’ai hâte que des collecteurs de traçage plus spécialisés (Zipkin, Flamegraph, etc.) arrivent.
Constant Evaluation
Oliver Schneider a ensuite partagé le travail en cours sur l’évaluation constante dans Rust. Comme beaucoup de langages compilés, Rust permet aux développeurs d’intégrer des variables dans le binaire, comme beaucoup de langages vous pouvez générer ces valeurs (macros en C) mais les options sont limitées.
C’est un problème pour de nombreuses langues, il se trouve que c’est aussi une discussion en cours dans le langage C++.
Comment générer un type qui alloue sur la heap au moment de la compilation et le rend disponible pour le binaire ? Quelles limitations ce type doit-il respecter pour être éligible à la génération pendant la compilation ?
Oliver a expliqué comment Rust essaie de repousser les limites de ce qui est possible et de ce qui doit être appliqué (pas de code dangereux, renforcer la correction (logique)…). L’équipe du compilateur a quelques idées pour ajouter un trait similaire à Send+Sync. Ceci est déjà disponible dans la version nightly.
Encore une fois, l’équipe du compilateur est prête à fournir plus de types, mais elle compte sur la communauté pour obtenir des commentaires sur ce qu’il faut fournir en premier ainsi que des cas d’utilisation.
Weld
Shoumik Palkar a ensuite parlé de Weld. Weld est un langage, un compilateur et une runtime pour les pipelines de données. Les auteurs sont partis de l’observation que les pipelines de traitement de données pouvaient gagner en performance en enchaînant les opérations au lieu de faire des allers-retours entre le CPU et la RAM. Par exemple, une simple tache de map-reduce, vous pouvez simplement réécrire le code pour scanner les données une seule fois et ne pas stocker les valeurs intermédiaires de la fonction map.
Donc Weld a commencé avec un compilateur en Scala qui transforme leur langage en un IR pour que la runtime letransforme en code-machine (GPU ou CPU) et l’exécute. Scala et Rust, deux langages fortement typés, sont des solutions particulièrement efficaces pour transformer l’AST en un IR optimisé.
Ils ont eu des problèmes avec la connexion de scala (étant basé sur la JVM) dans leur runtime et ont fini par réécrire le compilateur dans Rust (toutes les bibliothèques nécessaires pour s’accrocher dans LLVM sont déjà fournies par l’écosystème cargo).
Shoumik nous a expliqué certains des défis que pose la réécriture de scala dans Rust. Par exemple, ils ont dû apprendre à développer sans clone (qui copie les objets en RAM) qui était un tueur de performance pour les travaux de compilation et utiliser `mem::swap’ à la place.
C++
Ensuite Isabella Muerte – une vétéran du C++ avec une grande expérience en C++ (elle détient le record de la plupart des propositions soumises à une seule réunion ISO C++ et Rust – pour partager son expérience avec C++.
Elle a souligné à quel point C++ et Rust étaient similaires et comment ils ont deux points de vue différents sur les problèmes.
Mais ce qui m’a le plus frappé, c’est son retour sur les communautés, la façon dont les communautés de Rust ont pris position en faveur de l’inclusion dès le début et la façon dont elles ont travaillé pour un code de conduite. Elle a également fait valoir l’importance de la forme d’organisation pour un projet comme Rust. C+++ est réglementé par l’ISO, ce qui signifie qu’il est réglementé par les lois internationales afin que tout le monde puisse adhérer, mais l’argent est toujours nécessaire pour avoir une voix.
L’ECMA (l’organisation propriétaire de la norme javascript) est semblable à l’ISO, mais les entreprises ont la même voix que les organismes nationaux.
Contrairement à C++ et Javascript, Rust est toujours détenu et géré par Mozilla, qui est une société américaine. Cela signifie que les lois sur la propriété intellectuelle s’appliquent toujours, et Mozilla peut les utiliser devant les tribunaux pour menacer un autre acteur.
Edition 2018
La dernière présentation que j’ai vue a été donnée par Josh Triplett de l’équipe lang. Il nous a fait redécouvrir la nouvelle syntaxe introduite dans l’édition-2018 mais s’est concentré sur l’algorithme de résolution de chemin.
En 2017, Rust avait quelques incohérences concernant l’algorithme de recherche d’objet. L’équipe lang a donc travaillé pour trouver un algorithme plus cohérent. Ils sont arrivés avec une première version très cohérente, mais ils devaient casser la plupart du code en place. Alors que la solution avait l’air sympa, briser le code actuel ne l’était pas. Ils ont beaucoup parlé de cette solution, certains membres ont publié des articles de blog à ce sujet, et ils se sont finalement mis d’accord sur une solution plus stable, qui à la fois corrigeait les incohérences et permettait une transition en douceur.
L’expérience globale a pris du temps et il a fallu beaucoup d’efforts, de discussions et de va-et-vient pour trouver une solution satisfaisante pour tous. Je suis à titre personnel reconnaissant à l’équipe lang pour son travail acharné. L’expérience en tant qu’utilisateur est juste formidable !
Closing keynote
La closing keynote a été prononcé par Lin Clark. Lin a raconté qu’elle était une femme dans le domaine de la technologie et qu’elle s’apprêtait à quitter l’informatique en raison de problèmes connus d’inclusivité. Elle était curieuse vis-à-vis de Rust, de sa communauté et de ses dirigeants, et elle a finalement rejoint Mozilla et l’équipe Wasm là-bas.
On dirait qu’elle a prospéré là-bas, au moins jusqu’à présent, avec toute l’équipe des Wasm. Wasm est first-citizen pour Rust, et cela en fait une très bonne plateforme pour jouer avec Wasm. Lin nous a raconté ses expériences autour du Wasm, comment elle a été capable de construire un pont entre beaucoup de langages (Rust, go, PHP, python,…) et le Wasm dans les deux sens. Le résultat est si impressionnant qu’elle a été capable d’écrire Rust, de le compiler en Wasm, puis d’interagir avec lui de façon transparente en python et PHP non modifié. L’extension de Wasm dont elle a parlé est un livret attaché au byte-code de Wasm qui décrit les types et les points d’entrée du binaire, ce qui permet à chaque langue de traduire leurs types natifs en équivalent Wasm.
Cela ouvre beaucoup d’idées intéressantes sur la façon de câbler différentes bibliothèques entre les langages et les plates-formes.
C’est l’essentiel de ce qu’il y a à retenir de ma visite Rustconf. J’ai l’impression que l’immense majorité des conférenciers ont été reconnaissants à la communauté d’être si inclusive et si accueillante pour les nouveaux arrivants. Je le suis certainement aussi parce que l’aide que j’ai reçue lorsque j’ai appris la langue était inestimable, mais je dois dire que c’est la première fois que je participe à une conférence informatique avec autant de femmes et de personnes LGBTQ qui parlent ou participent, et il semble que la communauté Rust fait quelque chose de bien ici.
Dans l’ensemble, un grand merci à tous ceux qui ont participé à l’organisation, à la présentation et à l’adhésion à cette Rustconf, ce fut un grand moment, et j’ai hâte d’être à l’année prochaine.
Arthur est ingénieur système chez Gandi San Francisco. Pour toute question sur Rust ou le contenu développé ici, contactez-le sur Twitter : @baloose.
Tagged in conferencePartager l'article
