Transcript
00:00:00Vassel vient de sortir un nouveau langage de programmation appelé Xero, et apparemment,
00:00:03sa particularité est d'avoir été conçu de zéro pour que les humains et les agents IA
00:00:07puissent déployer de petits programmes natifs ensemble. Mais n'est-ce pas ce qu'on fait déjà tous ?
00:00:12Alors, qu'est-ce qui rend celui-ci meilleur ? Est-ce vraiment une bonne idée, ou juste un projet perso
00:00:16dont plus personne ne parlera dans quelques mois ? Voyons ça.
00:00:25Xero est un langage système comme Rust ou Zig, donc peut-être un truc avec lequel BUN se réécrira un jour.
00:00:30Et d'après ce que je vois, l'idée de départ est que les langages actuels ont été créés pour les humains.
00:00:34On lit donc les messages d'erreur, les avertissements et les traces, mais l'IA est bien plus efficace
00:00:38avec des données structurées. Avec Xero, toute la chaîne d'outils a été pensée dans ce sens,
00:00:43ce qui signifie que tout ce que produit le compilateur peut être sorti au format JSON.
00:00:46Rien qu'avec ces arguments, et les phrases visiblement générées par IA sur leur site web,
00:00:51je reste assez sceptique sur sa raison d'être et sur son efficacité réelle,
00:00:56mais je garderai mon avis pour la fin. Explorons d'abord le langage en lui-même,
00:00:59parce que ça reste quand même plutôt cool. Commençons par le grand classique
00:01:03quand on apprend un langage : afficher une simple chaîne. Presque tout est facile à comprendre.
00:01:08On a une fonction main publique comme point d'entrée du programme. Elle renvoie
00:01:12void, et à l'intérieur, on affiche une chaîne. Mais c'est la manière de l'afficher
00:01:16qui met en lumière nos premières fonctionnalités. On utilise la capacité “world”.
00:01:21Elle est requise pour toute opération d'E/S, comme manipuler des fichiers, afficher du texte ou appeler le réseau,
00:01:26bref, tout effet de bord d'E/S. Ça s'inscrit dans le principe d'explicité de ce langage.
00:01:31Si une fonction possède cette capacité “world”, on sait direct qu'elle fait des E/S,
00:01:37et si elle ne l'a pas, cela signifie qu'elle est exempte d'effets de bord d'E/S.
00:01:40Cette capacité permet aussi au compilateur de rejeter les capacités indisponibles selon la cible
00:01:45dès la compilation plutôt qu'à l'exécution. Si on tente d'accéder au système de fichiers
00:01:50dans cette fonction en ciblant un build WebAssembly, le compilateur renverra une erreur,
00:01:54ce qui évite d'avoir une mauvaise surprise avec une erreur d'exécution plus tard.
00:01:57Après la capacité “world”, on trouve aussi quelques mots-clés dans ce programme.
00:02:00Il y a “check” ici, qui sert à gérer les erreurs. Si une fonction peut échouer,
00:02:05on la marque avec “raises”, puis on utilise “check” pour propager cette erreur. C'est assez proche
00:02:09de l'opérateur point d'interrogation de Rust, mais sous forme de mot-clé. Voilà tout ce qu'il faut savoir
00:02:13pour notre premier programme en Xero. On peut le lancer avec “xero run hello.xero”.
00:02:19Notez que c'est l'extension de fichier pour le langage Xero. Si j'appuie sur Entrée,
00:02:23on voit s'afficher “hello, subscribe to Betastack”. Chose que vous devriez d'ailleurs faire.
00:02:26Mais passons à autre chose, maintenant qu'on est visiblement tous devenus des experts de Xero.
00:02:30Le langage propose d'autres primitives pour couvrir les besoins d'applications basiques.
00:02:34J'en ai fait une autre ici, une appli au pif qui classifie si l'entrée est textuelle,
00:02:39numérique ou mixte. On peut voir qu'elle utilise des fonctionnalités comme les bibliothèques standards.
00:02:43On a des enums, des shapes (très similaires aux structs), puis les éléments
00:02:47habituels attendus comme des blocs “if”, une boucle “while” plus bas, on peut aussi
00:02:52utiliser des boucles “for”, et on a aussi un “match” ici qui s'apparente à un “switch”.
00:02:56Rien de très surprenant ou de nouveau. Pour les concepts avancés comme la mémoire, là encore avec Xero,
00:03:00tout doit être explicite. On a des “mutable spans” pour les vues en écriture et des “spans”
00:03:05pour les vues en lecture. En bas, on a un type “owned”. Ça indique que la valeur est
00:03:10possédée ici, et qu'on doit exécuter la fonction “drop” quand elle sort du scope. On définit
00:03:14nous-mêmes la fonction “drop” sur la shape, c'est là qu'on met notre logique de nettoyage. Une autre
00:03:18façon de faire est d'utiliser le mot-clé “defer” suivi d'une fonction. En gros,
00:03:22ça signifie que lorsque cette fonction est terminée et sort de son scope, on exécute celle-ci après. Donc
00:03:26il y a vraiment tout le nécessaire pour une application très basique aujourd'hui. Il y a d'autres fonctions,
00:03:31mais je ne veux pas que ça devienne un tuto de code. N'hésitez pas pour autant à ajouter
00:03:35vos trois minutes d'expérience en Xero sur votre CV. Ceci étant dit, concentrons-nous sur ce qui
00:03:39est selon moi le vrai argument de Xero : sa chaîne d'outils et le fait qu'elle ait été pensée pour les agents IA.
00:03:44Imaginez qu'un agent IA écrive du code Xero et y glisse des bugs. Ils affirment que
00:03:49dans la plupart des langages, on récupère un gros pavé de texte avec des messages d'erreur conçus
00:03:54pour être lus par des humains. Avec Xero, on peut avoir cette version lisible par l'humain,
00:03:58qui ressemblera à ça, mais comme on peut le voir, ce n'est pas un résultat structuré. Ils ont donc veillé
00:04:02à ce que chaque élément de la chaîne d'outils propose une option JSON. Si on relance la même fonction,
00:04:07mais cette fois-ci avec l'option JSON, et en passant le tout dans JQ pour que ce soit plus propre,
00:04:12on constate qu'on obtient un message d'erreur avec un rendu bien structuré. On a des diagnostics comme la
00:04:16sévérité, le code et le message. On sait où l'erreur se produit, la valeur attendue et sa
00:04:21valeur réelle. On a aussi de l'aide destinée au LLM lui-même, ainsi qu'un champ de sécurité de correction
00:04:26indiquant si une révision humaine est requise, avec des infos sur la méthode de réparation. Le but est
00:04:31juste de donner assez de contexte au LLM pour qu'il corrige le tir tout seul. Une autre commande l'illustre
00:04:35très bien : “xero fix”. Je l'utilise ici avec le mode plan ainsi que le JSON, en passant toujours
00:04:40le tout dans JQ pour le visuel dans notre terminal. Quand j'appuie sur Entrée,
00:04:44la commande effectue un diagnostic sur le fichier corrompu que je lui ai fourni, et elle indique en gros
00:04:49ce qu'il faut faire pour réparer ce fichier. On voit qu'on récupère un résultat structuré avec des champs
00:04:53que seul un LLM a besoin de connaître, comme les niveaux de sécurité, le mode, les applications, l'édition. On a
00:04:58des éléments plus bas comme la politique de réparation auto-hébergée. On retrouve ensuite la section diagnostic,
00:05:03qui est globalement identique à ce qu'on a vu avec la commande “xero check”, et en dessous, on a la correction pour ce code
00:05:07d'erreur spécifique. Comment est-ce corrigé d'habitude ? En fait, une partie de l'idée semble être : et si le langage
00:05:12fournissait sa propre documentation au moment voulu ? Si on soumettait ce nouveau langage à un LLM,
00:05:17il n'aurait pas vraiment besoin de chercher de la doc ou d'utiliser des compétences spécifiques, il lui suffirait
00:05:21de récupérer les informations de la chaîne d'outils quand il en a besoin. Pour tester ça, j'ai mis
00:05:25notre fichier corrompu dans un tout nouveau répertoire qui ne contient aucune info sur le langage Xero, et maintenant,
00:05:30je demande simplement à Claude de corriger ce fichier défectueux, en lui fournissant la commande requise
00:05:34pour ces diagnostics, puisqu'il a besoin d'explications sur l'utilisation de la chaîne d'outils. À partir de
00:05:38là, on va voir si Claude arrive à corriger le fichier. Et voilà, après 31 secondes, il a réussi à
00:05:43corriger toutes les erreurs du fichier. J'en avais glissé trois, il les a toutes trouvées
00:05:47et corrigées, et on peut remonter pour voir comment il s'y est pris. Il a simplement exécuté la
00:05:51commande “xero fix” que je lui avais donnée. Cette fois-ci, on a récupéré “okay true”, c'est comme ça qu'il sait qu'il n'y a plus
00:05:56d'erreurs. Et si on remonte, on voit qu'il a fait des modifications de code parce que
00:06:00lors de l'étape précédente, il a lancé “xero fix” et obtenu des informations précises sur la méthode de résolution,
00:06:05et il a répété ça pour nos trois problèmes. Donc, il n'avait aucune information préalable sur ce qu'est
00:06:10le langage Xero, il n'a fait aucune recherche web ou autre pour récupérer de la documentation, il a
00:06:14simplement exploité les informations fournies sous forme de sorties structurées par la chaîne d'outils. Je suis
00:06:18assez impressionné par ça. C'est un tout nouveau langage qu'un LLM arrive quand même à déboguer grâce
00:06:22à la façon dont le langage a été construit. Mais une question me trotte dans la tête : est-ce vraiment si nouveau ? Je
00:06:28comprends tout l'intérêt d'avoir des erreurs et des éléments de la chaîne d'outils qui proposent des sorties
00:06:31structurées, mais le concept n'est pas si récent, on a des messages d'erreur structurés depuis des décennies. Regardez
00:06:37ça : j'ai à peu près le même programme de classification codé en Rust, il a des erreurs similaires
00:06:41et je peux tout à fait demander un rendu au format JSON. Je ne suis pas vraiment sûr qu'on avait besoin de bâtir
00:06:46un langage entier autour de cette idée, on aurait peut-être pu simplement améliorer l'existant si on estimait
00:06:51qu'il manquait des informations. Je suis aussi persuadé que si je prenais ce code Rust défectueux pour demander à
00:06:55Claude de le corriger, il le ferait sans problème, et ce même sans utiliser de sorties
00:07:00structurées. J'ai l'impression que les LLM s'en sortent très bien avec des messages normaux, ou alors je n'ai
00:07:05jamais été confronté au problème. À cela s'ajoute le fait que les LLM ont été entraînés sur d'immenses volumes de
00:07:10langages de code existants comme Rust, ils sont donc très doués pour déboguer ça car ils disposent de tas
00:07:14d'exemples dans leurs données d'entraînement, alors qu'avec Xero, ils n'en ont absolument aucun. Ça ne veut pas dire qu'il ne
00:07:19faut jamais tenter de lancer un nouveau langage, mais simplement que pour concevoir une appli complexe, on ne se tournerait pas
00:07:24vers Xero. Pour être honnête, ils ne le vendent pas vraiment comme ça de toute façon. Au final,
00:07:28je trouve que c'est une expérience sympa, et ça montre au moins qu'on peut tout à fait créer un nouveau langage
00:07:32et donner le contexte requis aux LLM sans qu'ils aient été entraînés dessus, mais je ne sais pas trop
00:07:37si c'était vraiment nécessaire. Ça ne veut pas dire pour autant que le langage en lui-même n'est pas cool. Comme je l'ai dit,
00:07:42il est plutôt agréable à utiliser et il compile dans un volume tout à fait raisonnable. J'ai juste des doutes sur le fait que
00:07:47je l'utilise un jour à la place de valeurs sûres comme Rust, Zig ou Go. Je me doute qu'il y aura plein
00:07:51d'avis différents là-dessus, alors dites-moi ce que vous en pensez dans les commentaires ci-dessous, ou abonnez-vous,
00:07:55et comme d'habitude, on se retrouve dans la prochaine.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video