Rust on Benjamin Geer

Créer des applications hypermédia sécurisées pour un monde aux ressources limitées

Mon, 05 Oct 2026 07:00:00 +0000

Quand je développais des applications web dans les années 1990, il était courant que le server génère des pages HTML à partir de templates, et beaucoup de moteurs de template ont été créés pour cela (y compris par moi). À partir du début des années 2000, les applications web monopages se sont répandues. Dans celles-ci, le serveur renvoie surtout des données au format JSON, alors qu’un framework JavaScript (ou TypeScript) génère le code HTML dans le navigateur. J’ai travaillé sur des applications de ce type et j’ai constaté qu’elles sont difficiles à maintenir, en partie parce que les frameworks JavaScript sont gigantesques et complexes et évoluent rapidement.

On constate aujourd’hui un mécontentement croissant vis-à-vis des applications monopages, non seulement à cause des difficultés de maintenance, mais aussi parce que ces applications doivent charger plusieurs mégaoctets de JavaScript via le réseau avant de pouvoir fonctionner, ce qui les rend lentes, surtout quand la connexion réseau est lente. En même temps, HTML est devenu plus puissant, ce qui rend JavaScript moins indispensable. Par conséquent, il y a un regain d’intérêt pour la génération de code HTML côté serveur.

Un des inconvénients de la génération de code HTML côté serveur dans les années 1990 était la nécessité de recharger la page entière dès qu’un élément changeait. Aujourd’hui cette limitation n’existe plus, grâce à des bibliothèques JavaScript minuscules comme htmx. En ajoutant des attributs déclaratifs aux éléments HTML, on peut permettre à toutes sortes d’interactions utilisateur de récupérer des fragments de code HTML depuis le serveur et de ne remplacer que les parties de la page qui doivent être modifiées. Les applications qui fonctionnent de cette façon sont des « applications hypermédia », et il y a un livre là-dessus qui s’appelle Hypermedia Systems.

Le livre explique la construction d’une application de gestion de contacts à l’aide de htmx, et le code source est fourni en Python. L’ouvrage étant axé sur htmx, le code serveur est très simple : il ne prend en charge que l’anglais, les contacts sont stockés dans un fichier plutôt que dans une base de données, la validation des entrées est très limitée, la pagination est basée sur des numéros de page et il n’y a pas de tests.

Dans un monde aux ressources limitées, il est logique de développer ce type d’applications dans des langages qui se compilent en code machine et utilisent relativement peu de mémoire.¹ Nous aimerions avoir la possibilité d’utiliser une base de données très légère comme SQLite ou d’en choisir une plus puissante comme PostgreSQL. Pour éviter les bugs et les failles de sécurité, nous pouvons privilégier les langages à typage statique qui mettent l’accent sur les fonctionnalités de sécurité intégrées. Et nous aimerions que notre application soit facile à maintenir.

Compte tenu de ces préférences, rendons l’application de Hypermedia Systems plus réaliste. Nous allons y ajouter une interface utilisateur internationalisée, une base de données relationnelle avec un index de recherche en texte intégral, une meilleure validation des entrées, une pagination par curseur et des tests d’interface utilisateur. Dans les prochains articles, je présenterai deux implémentations, l’une en Go et l’autre en Rust, utilisant soit SQLite, soit PostgreSQL. J’expliquerai les choix de conception que j’ai faits dans chaque version et j’aborderai des techniques intéressantes qui ont des applications plus larges. N’étant pas concepteur UX, je ne chercherai pas à améliorer l’interface utilisateur décrite dans le livre, mais j’aurai quelques mots à dire sur ce qui peut faciliter le travail des concepteurs UX. Je ne couvrirai pas la plupart des détails expliqués dans Hypermedia Applications, mais vous pouvez lire ces articles sans avoir lu le livre. Réfléchissons donc à des techniques que nous pouvons utiliser pour développer des applications web sécurisées, économes en ressources et faciles à maintenir :

(Ces deux articles peuvent être lus indépendamment l’un de l’autre.)

La relation entre l’efficacité énergétique et le choix du langage de programmation constitue un domaine de recherche très actif. Voir Energy Efficiency of Programming Languages. ↩︎

Comparer les performances de requêtes SQL

Thu, 29 Jan 2026 18:25:18 +0100

J’ai réalisé un petit programme en Rust, sqlstopwatch, pour comparer les performances de différentes requêtes SQL. J’ai été inspiré par l’article Benchmarking SQL publié par le projet jOOQ, dans lequel le code du test est implémenté en SQL. Je voulais quelque chose de semblable, mais j’avais quelques exigences supplémentaires :

Un programme en ligne de commande avec une interface utilisateur simple en mode texte (TUI) qui affiche une barre de progression.
Le programme devrait prendre en charge PostgreSQL, MySQL et SQLite.
Il devrait lire les requêtes SQL et les paramètres du test dans un fichier de configuration indiqué sur la ligne de commande.
Il devrait afficher les résultats sous forme de table dans le terminal ou les enregistrer dans un fichier au format CSV que je puisse utiliser pour générer un diagramme.

L’interface utilisateur a été facile à réaliser avec Ratatui. Pour interagir avec la base de données, j’ai utilisé la bibliothèque asynchrone sqlx, qui fournit une bibliothèque SQLite embarquée.

J’ai pensé à utiliser le format TOML pour le fichier de configuration, mais le fichier doit fournir les identifiants de connexion. Dans les environnements de test, il se peut que les identifiants doivent être chargés à partir de variables d’environnement ou de fichiers sur un système de fichiers monté, mais TOML ne permet pas d’effectuer de telles opérations. En plus, on pourrait vouloir générer plusieurs requêtes similaires pour les comparer, comme je l’ai fait dans ce projet d’optimisation de base de données. Par conséquent, il vaut mieux que le fichier de configuration soit un programme dans un langage de script. Mon exercice d’implémentation d’un interpréteur de langage de script m’avait permis d’apprécier à sa juste valeur la machine virtuelle Lua. Le fichier de configuration est donc un script en Lua, que je trouve plus commode de rédiger en Fennel, un dialect de Lisp qui se compile en Lua. Grâce à la bibliothèque mlua, il a été très facile d’embarquer un interpréteur Lua dans le programme et d’utiliser Serde pour convertir des tables Lua en structs Rust.

Créer un client Bittorrent en Rust

Thu, 15 Jan 2026 15:16:01 +0100

Aperçu #

Pour continuer mon apprentissage de Rust, j’ai décidé de réaliser un client pour Bittorrent, le protocole de transfert de données pair-à-pair. Les clients Bittorrent que j’ai utilisés ont des interfaces graphiques complexes qui semblent destinées aux gens qui téléchargent des torrents à longueur de journée, plutôt que pour l’utilisateur occasionnel comme moi, qui veut tout simplement obtenir un seul fichier. Et comme beaucoup d’applications à interface graphique, les clients Bittorrent ont tendance à accumuler des fichiers qui occupent de l’espace disque dans des répertoires obscurs. Je fais beaucoup de choses dans le terminal et quand j’ai besoin de télécharger un fichier, mon réflexe est d’utiliser curl. Je me suis donc dit, pourquoi ne pas créer quelque chose comme curl pour Bittorrent ? En pensant à l’indicateur de progression de curl, l’idée m’est venue à l’esprit de faire quelque chose de semblable avec Ratatui, une bibliothèque de création d’environnements en mode texte (TUI), que je voulais de toute façon essayer.

La réalisation d’un client Bittorrent semblait être une bonne occasion d’apprendre la programmation asynchrone en Rust. J’avais lu beaucoup de critiques d’async en Rust, mais je l’ai trouvé agréable à utiliser (en utilisant la bibliothèque Tokio) et certainement plus confortable que les infrastructures logicielles comparables que j’avais utilisées en Scala (Akka et Cats Effect). J’aime particulièrement le fait qu’une fonction async peut être exécutée dans une tâche existante ou dans sa propre tâche, à la différence du Future de Scala, qui est affecté à un fil d’exécution et se lance dès sa construction. L’approche de Rust semble mieux adapté au remaniement et à la maintenabilité. En même temps, je suis content de ne pas avoir à gérer la complexité liée à l’utilisation des monades comme dans Cats Effect.

Le résultat est Sayaca, qui porte le nom d’un oiseau sud-américain qui joue un rôle important dans la dispersion des graines (le verbe anglais to seed veut dire ensemencer, et dans la terminologie de Bittorrent, envoyer des données aux autres pairs).

La conception #

Ma première tâche a été de réaliser un analyseur syntaxique pour Bencode, le format de données utilisées dans le protocole Bittorrent. Au niveau conceptuel, Bencode ressemble à JSON, mais il est destiné à la représentation de données binaires plutôt que textuelles. J’avais envie d’essayer d’utiliser une bibliothèque de combinateurs d’analyseurs syntaxiques, et je n’ai pas eu de mal à implémenter l’analyseur en utilisant nom. Comme je voulais être en mesure de sérialiser et de désérialiser des structs en Rust au format Bencode, j’ai ajouté la prise en charge de la bibliothèque Serde. J’ai publié la crate issue de ce travail sous le nom de bside.

La principale difficulté dans la conception du client résidait dans le caractère confus des spécifications Bittorrent. Il y a des ambigüités (le mot piece a deux sens différents) et les implémentations se sont écartées des spécifications (par exemple, les identifiants de pair ne sont pas utilisés pour identifier les pairs). Une grande partie des informations relatives au protocole ne figure pas dans les spécifications officielles, mais dans d’autres documents dispersés sur le Web. Il y a une longue liste (non mise à jour depuis 2018) de projets d’extension du protocole qui sont pris en charge par de nombreux clients. Une extension dite de chiffrement (qui semble en réalité décrire une forme de brouillage) semble être largement mise en œuvre, mais d’après ce que je peux en juger, depuis 2023, sa spécification n’est conservée que dans la Wayback Machine de l’Internet Archive. Il existe un projet de spécification du protocole BitTorrent v2 (non mis à jour depuis 2017) qui tente de corriger certains défauts du protocole d’origine, comme sa dépendance vis-à-vis de la fonction de hachage SHA-1 (qui n’est plus considérée comme sécurisée depuis 2005). J’aurais pu errer longtemps dans un dédale de documents et dans le code source des clients existants. Pour simplifier les choses, j’ai décidé de ne mettre en œuvre que le protocole d’origine et l’extension IPv6 tracker.

Quand un client Bittorrent enregistre des données sur le disque, il devrait offrir de bonnes performances avec des fichiers volumineux, être capable d’interrompre un téléchargement et de le reprendre plus tard (ce qui signifie qu’il doit noter quels fragments ont été téléchargées) et gérer les torrents qui comprennent plusieurs fichiers. Pour faire tout cela, et pour que les choses soient claires pour l’utilisateur, j’ai choisi d’enregistrer les données téléchargées dans un fichier intermédiaire (avec l’extension .sayaca), dans le même répertoire où les fichiers finaux seront enregistrés. Le fichier intermédiaire contient un champ de bits indiquant les fragments qui ont été téléchargés (il s’agit du même champ de bits qu’il faut de toute façon envoyer aux pairs). Pour lire et écrire ce fichier, Sayaca utilise la projection en mémoire, ce qui devrait offrir de bonnes performances d’entrée-sortie avec des fichiers volumineux. Une fois le téléchargement terminé, il copie les données depuis le fichier intermédiaire vers les fichiers finaux. Lorsque le programme se ferme, le fichier intermédiaire est supprimé s’il n’est plus nécessaire.

Comme un client Bittorrent est tributaire des entrées-sorties (I/O bound), j’ai décidé d’employer une architecture événementielle dans laquelle une seule tâche accomplit la majeure partie du travail, comme dans Redis. Cette tâche principale délègue toute les entrées-sorties réseau à d’autres tâches, avec lesquelles elle communique via des canaux. Cela a été très simple à mettre en œuvre et a eu l’avantage de rendre facile la création de tests unitaires pour la tâche principale.

Une grande partie du travail effectué par un client Bittorrent revient à tenir une sorte de comptabilité. Dans Sayaca, ce travail est la responsabilité du Bookkeeper (« comptable »). Par exemple, dans l’algorithme recommandé de sélection des fragments à demander aux pairs, le client essaie de demander d’abord les fragments les plus rares. Cela nécessite une structure de données qui note les fragments dont dispose chaque pair, ainsi que la rareté de chaque fragment, entre autres. Il y a plusieurs façons de réaliser cela et j’ai décidé d’utiliser un tableau associatif ordonné, trié par ordre de rareté, pour stocker les identifiants de fragments et les ensembles de pairs qui les possèdent. Le Bookkeeper peut ainsi trouver facilement un fragment, choisi au hasard parmi les plus rares, associé à un pair choisi au hasard parmi ceux qui possèdent ce fragment et qui nous ont autorisé à leur envoyer des demandes. Ainsi une grande partie du travail du client consiste à mettre à jour le Bookkeper lors de la réception de nouvelles informations et à l’interroger pour savoir ce qu’il faut faire ensuite.

J’aime bien les TUI et il a été facile de créer un TUI simple avec Ratatui. Mais comme le client est une bibliothèque qui communique avec son interface utilisateur via des canaux, il serait simple d’intégrer le client dans une autre interface utilisateur, comme une interface en ligne de commande plus accessible.

D’autres approches possibles #

J’ai choisi d’utiliser Tokio parce que je voulais en savoir plus à son sujet et sur async, mais je pense que le programme n’aurait probablement pas été très différent si j’avais utilisé des fils d’exécution à la place, avec la même communication via des canaux.

Créer une machine virtuelle en Rust

Sun, 12 Oct 2025 00:00:00 +0000

Aperçu #

Pour m’aider à apprendre le langage Rust, j’ai décidé de réaliser un interpréteur pour Lox, le langage de script que Robert Nystrom a créé pour son livre Crafting Interpreters. Je m’intéresse aux langages de script qui sont destinés à être embarqués dans des applications, et cet exercice m’a semblé un bon moyen d’en savoir plus sur la construction de ce type de langage.

Le livre de Nystrom présente, étape par étape, le développement de deux versions de l’interpréteur. Alors que la première, en Java, parcourt un arbre de syntaxe abstraite (AST) pour exécuter un script, la deuxième, en C, comporte une machine virtuelle qui exécute du bytecode. Cette deuxième version m’intéressait davantage. Au fil des ans, j’avais réalisé deux interpréteurs qui parcourent des arbres de syntaxe abstraite, en commençant par Apache FreeMarker, ainsi qu’un compilateur source à source optimisant utilisant l’inférence de types. Mais je n’avais pas encore fait de machine virtuelle. L’idée me rappelait de bons souvenirs de programmation en assembleur sur l’Apple II quand j’avais quinze ans. Le jeu d’instructions de la machine virtuelle de Nystrom est plus simple que celle du processeur Motorola 6502 de l’Apple II, mais le principe est le même. J’ai donc sauté la première partie du livre pour aller directement à celle où il s’agit de la machine virtuelle.

Le résultat est OrganicLox. La conception est globalement celle présentée dans le livre, mais j’ai essayé de coder dans un Rust courant, en visant des performances raisonnables, sans écrire de code non sécurisé. Les fonctionnalités d’OrganicLox devraient être identiques à celles du programme clox de Nystrom : au moins, ses 246 tests automatisés passent.

J’ai décidé de ne pas créer mon propre ramasse-miettes, car tout le monde semble s’accorder à dire que les ramasse-miettes sont particulièrement difficiles à réaliser en Rust. Par souci de simplicité, j’ai opté plutôt pour le comptage des références (au moyen de Rc). Sur la branche main, cela veut dire que les cycles de propriétés d’objets ne seront pas nettoyés. Sur la branche with_dumpster_gc, j’ai remplacé Rc par la crate dumpster, qui assure le comptage des références et nettoie aussi les cycles.

Ce que j’ai préféré #

J’ai beaucoup aimé ce livre : les explications claires de Nystrom, ses illustrations utiles, son style léger et son humour ont rendu le livre agréable à lire.

Pour moi, la mise en œuvre des variables locales et des fermetures dans une machine virtuelle à pile ont été parmi les aspects les plus intéressants de la conception que présente Nystrom, conception qui s’inspire largement de celle de l’interpréteur Lua. J’ai aimé apprendre que le compilateur associe les variables locales à des positions spécifiques sur la pile, de sorte que la machine virtuelle n’a besoin de connaître que ces positions et non pas les noms des variables concernés.

La mise en œuvre des upvalues, à savoir les variables qui sont capturées par les fermetures et qui doivent donc éventuellement être allouées sur le tas, n’a pas été simple à faire correctement. En corrigeant un bogue, j’ai été heureux de me rendre compte que l’appel récursif d’une function définie dans une portée locale nécessite que la fermeture de la fonction soit une des ses propres upvalues.

Ce que j’aurais souhaité #

Les explications de Nystrom sont tantôt ascendantes, tantôt descendantes. L’approche ascendante a présenté plus de difficultés quant à la traduction de sa conception en Rust, car je devais deviner où il voulait en venir. Plusieurs fois j’ai dû remanier beaucoup de code parce que je n’avais pas deviné juste. Comme l’implémentation de Lox dans toutes sortes de langages de programmation semble être un exercice courant, il aurait été utile d’avoir plus souvent une vue d’ensemble de la conception.

Cela m’a fait plaisir de découvrir la technique de Pratt pour construire un analyseur syntaxique descendant reposant sur la précédence des opérateurs et de constater qu’il est vraiment possible de générer du bytecode sans d’abord construire un AST. Mais il aurait peut-être été plus utile de construire un AST et d’apprendre quelque chose sur la conception d’une deuxième phase pour optimiser le bytecode.

La performance #

L’optimisation principale que j’ai faite au départ a été de faire en sorte que l’analyseur lexical mette tous les identifiants dans un pool de chaînes de caractères (en utilisant string_interner), pour que ni le compilateur ni la machine virtuelle aient à comparer des chaînes représentant des identifiants.

Après avoir fini le chapitre 24, j’ai passé un peu de temps à me pencher sur la performance, en suivant les conseils du Rust Performance Book. J’ai fait des tests de performance avec criterion et du profilage avec perf et hotspot, j’ai ajusté la configuration du compilateur Rust and j’ai marqué quelques fonctions inline.

Ensuite j’ai regardé quelques autres versions de Lox en Rust et j’ai remarqué que tout le monde semble avoir eu du mal à obtenir des performances proches de celles du clox de Nystrom et que les versions qui y arrivent comportent beaucoup de code non sécurisé, ce que je voulais éviter.

Je recommande vivement billet de blog de Manuel Cerón sur sa tentative impressionnante, déterminée et partiellement réussie d’égaler la vitesse de clox en Rust en écrivant de plus en plus de code non sécurisé.

À titre de comparaison, voici les résultats de l’exécution de quelques-uns des tests de performance de Nystrom sur les versions suivantes :

Le clox de Nystrom
La version sécurisée du loxido de Cerón
La version non sécurisée de loxido
OrganicLox avec Rc
OrganicLox avec le ramasse-miettes dumpster

OrganicLox avec Rc est donc deux à quatre fois plus lent que clox, ce qui est peut-être typique des interpréteurs réalisés en Rust par rapport à ceux réalisés en C. La version avec dumpster est beaucoup plus lente. Il semble clair qu’un ramasse-miettes rapide est essentiel pour une machine virtuelle très performante.

Quelle est l’importance de ces différences ? Les tests de performance sont conçus pour simuler des scénarios extrêmes, par exemple en utilisant de longues boucles ou la récursivité profonde, ou en créant une charge de travail importante pour le ramasse-miettes. Ils ne sont donc pas forcément représentatifs des cas d’utilisation réels. Il arrive souvent que les scripts exécutés par une application dans un interpréteur embarqué sont courts et font très peu de travail. On pourrait se faire une idée plus réaliste de la performance d’une machine virtuelle dans un tel scénario en exécutant la suite de tests d’intégration de Nystrom, qui exécute 246 scripts courts en Lox et vérifie leurs sorties. Voici une comparaison :

Dans une application où chaque cycle CPU compte, les écarts entre les performances de ces différentes implémentations pourraient avoir beaucoup d’importance. Mais dans d’autres cas d’utilisation, ils pourraient être insignifiants.

D’autres approches possibles #

Il est tentant d’essayer d’ajouter un compilateur à la volée (JIT) pour améliorer la performance de l’interpréteur, soit en en écrivant un à partir de zéro, soit en en utilisant un backend existant comme LLVM ou Cranelift. Roto et Dora sont des exemples en Rust de cette approche. Mais même si on adopte cette démarche, il n’est pas facile d’atteindre un haut niveau de performance. Dans ces tests de performance, le nouveau JIT de Python n’a aucun effet mesurable sur les performances (voir aussi ces résultats de tests de la performance de Dora).

Voilà une raison d’envisager d’utiliser un interpréteur existant qui a déjà bénéficié d’années de développement, plutôt que d’en créer un nouveau. Le langage Lua est une option largement utilisée, mais il n’est pas assez rapide pour certaines applications. La machine virtuelle LuaJIT est un ordre de grandeur plus rapide que la machine virtuelle Lua standard pour certains cas d’utilisation, mais c’est un compilateur à la volée basé sur les arbres de traces, ce qui a des avantages et des inconvénients. Les développeurs de Lua ont publié un article intéressant qui traite des limites de cette approche et propose une autre solution (un langage supplémentaire à typage statique, un peu comme Cython).

Pour certains cas d’utilisation, si des scripts embarqués ne font pas beaucoup de travail, leurs performances pourraient ne pas être critiques. S’ils font tellement de travail que leurs performances sont insuffisantes, une autre option consiste à ne pas intégrer d’interpréteur du tout. Cloudflare, qui avait investi massivement pendant plus de 20 ans dans des scripts en utilisant LuaJIT embarqué dans OpenResty, les a récemment remplacés par du code Rust.