Moonbit : un langage WebAssembly rapide, concis et convivial

 (moonbitlang.com)
2 points par GN⁺ 2023-08-20 | 1 commentaires | Partager sur WhatsApp
  • Alors que WebAssembly gagne en importance dans le cloud et l’edge computing, Moonbit vise à être un langage orienté Wasm qui facilite l’exploitation de l’efficacité, de la sécurité et de la petite taille de Wasm
  • Moonbit cible les limites de Rust et C/C++, dont la courbe d’apprentissage et les longs temps de compilation sont contraignants, ainsi que celles de Go, dont le code généré est volumineux et peu efficace
  • La conception met l’accent sur des builds et une exécution rapides, une sortie Wasm compacte et une grande facilité d’utilisation, avec notamment l’optimisation via plusieurs représentations intermédiaires, l’analyse sémantique parallèle au niveau des fonctions et la réanalyse incrémentale
  • L’exemple de Fibonacci met en avant l’inférence de type pour les fonctions locales, la plus petite sortie Wasm, de meilleures performances que Go et comparables à Rust, ainsi que la prise en charge des closures récursives et de l’exhaustive pattern match
  • Le projet propose déjà un IDE en ligne, des outils CLI, de la documentation et une extension VSCode, et vise le beta status d’ici la fin du 2e trimestre 2024, avec ouverture du code source après avoir atteint une qualité bêta

Objectif : un langage centré sur WebAssembly

  • WebAssembly est une architecture de jeu d’instructions multiplateforme dont l’importance grandit dans le cloud et l’edge computing en raison de son efficacité, de sa sécurité, de sa petite taille et de son statut de standard ouvert
  • Selon l’équipe, les options existantes n’exploitent pas pleinement le potentiel de Wasm
    • Les langages Wasm de bas niveau comme Rust et C/C++ sont difficiles à apprendre, et leurs longs temps de compilation peuvent ralentir le développement
    • Les langages de plus haut niveau comme Go produisent un code inefficace et volumineux, ce qui rend plus difficile de tirer parti de la rapidité et de la compacité de Wasm
  • Moonbit se veut un langage Wasm-first qui compile et s’exécute rapidement, produit une sortie Wasm compacte et reste aussi facile à apprendre que Go

Conception du langage et équipe

  • Moonbit est dirigé par Hongbo Zhang et une équipe disposant de plus de 10 ans d’expérience en conception et développement de langages
  • Zhang a contribué à OCaml, ReScript et Flow, et a occupé le rôle de chief architect pour le compilateur rapide, la bibliothèque standard et le système de build de la toolchain ReScript
  • La conception du langage s’inspire à la fois de Go et de Rust
    • Il reprend la simplicité de Go, en particulier le système de packages
    • Il reprend aussi l’expressivité de Rust, notamment le pattern matching, l’inférence de type, les génériques et un polymorphisme ad hoc proche des traits
  • Le système de types fault tolerant a été conçu en tenant compte de la vitesse, de la parallélisation et de la vérification incrémentale, avec le support IDE comme objectif central

Builds et exécution rapides

  • Moonbit vise à être un langage rapide sur toute la pile, à la fois en performances de développement et en performances d’exécution
  • Il utilise plusieurs niveaux de représentations intermédiaires (IR) pour permettre des optimisations sur l’ensemble du programme
    • L’objectif est d’améliorer l’agencement mémoire afin de réduire les défauts de cache
    • Cela fournit un meilleur contexte pour l’analyse des flux de données et de contrôle
    • Selon l’équipe, cela permet de comprendre la structure du programme plus globalement que la plupart des architectures classiques de link-time optimization, et donc d’optimiser plus efficacement
    • Cela permet aussi de détecter et supprimer des redondances de haut niveau invisibles à plus bas niveau
  • Pour obtenir les performances de build rapides importantes pour les fonctionnalités IDE, Moonbit autorise l’analyse sémantique parallèle au niveau des fonctions
    • Contrairement à ReScript et Rust, l’analyse sémantique parallèle au niveau des fonctions est possible
    • Une réanalyse incrémentale à cette même granularité permettrait de gérer de grands monorepos et d’offrir des temps de réponse de l’ordre de la milliseconde

Une sortie Wasm compacte

  • Moonbit a été conçu en gardant à l’esprit une dead code elimination efficace
  • Les fonctionnalités du langage qui compliqueraient cette analyse ont été exclues, et la bibliothèque standard est elle aussi structurée pour faciliter l’élimination du code mort
  • L’objectif est de réduire fortement la taille du code final grâce à l’optimisation globale du programme
    • Une réduction de la taille du code améliorerait la sécurité et réduirait la surface de vulnérabilité
    • Cela garantirait aussi un démarrage rapide dans les environnements de calcul serverless

Fonctionnalités et outils pensés pour l’usage

  • Moonbit propose une gestion automatique de la mémoire, ce qui le distingue de Rust
  • Contrairement à Go, il dit éviter des éléments risqués comme les pointeurs ou les left values
  • Il fournit des fonctionnalités sûres pour une programmation orientée données
    • algebraic data types
    • ad-hoc polymorphisms
    • pattern match
  • Au-delà du langage, il vise aussi un rôle de plateforme et fournit déjà un ensemble d’outils dès ses débuts
    • outil de build rapide
    • gestionnaire de packages
    • compilateur
    • IDE
    • Cloud IDE sans conteneur, accessible partout avec un simple navigateur
    • Ce Cloud IDE proposerait aussi des fonctionnalités hors ligne, ce qui le distinguerait des IDE cloud existants

Différences illustrées avec l’exemple Fibonacci

  • L’exemple Fibonacci compare l’implémentation de la fonction fib en MoonBit, Go et Rust
  • Selon le benchmark, MoonBit se distingue en matière d’inférence de type, de taille du code, de performances et d’utilisabilité
    • Inférence de type locale : MoonBit infère le type de la fonction locale aux
    • Petite taille Wasm : MoonBit génère la sortie Wasm la plus compacte
    • Performances : plus rapide que Go et comparable à Rust
    • Utilisabilité : prend en charge les closures récursives comme Go, ce qui serait très difficile à mettre en œuvre en Rust
    • Comme Rust, il prend en charge l’exhaustive pattern match, jugé bien plus puissant que les switch case de Go

État actuel et feuille de route

  • Moonbit est encore en évolution rapide, mais propose déjà plusieurs points d’entrée utilisables
  • Le développement d’une toolchain de langage demandait autrefois de plusieurs années à une décennie, mais l’équipe affirme avoir simplifié ce travail grâce à l’expérience accumulée et à une équipe dédiée constituée dès le départ
  • L’objectif est d’atteindre le beta status d’ici la fin du 2e trimestre 2024
    • Le beta status signifie une stabilité relative, peu de bugs et une FFI robuste pour interagir avec les hôtes Wasm
  • Le code source sera publié après l’atteinte d’une qualité bêta
  • Les plans stratégiques comprennent l’intégration de Wasm GC pour Wasm 2.0 ainsi qu’un GC propriétaire pour Wasm 1.0, en phase avec les propositions Wasm

Canaux communautaires

À lire aussi

1 commentaires

 
GN⁺ 2023-08-20
Avis sur Hacker News

  • Je suis le lead de ce projet. Vous pouvez l’essayer dès maintenant dans l’IDE en ligne https://try.moonbitlang.com et l’exécuter avec F5.
    La documentation est disponible sur https://github.com/moonbitlang/moonbit-docs, et le compilateur sera rendu public lorsqu’il atteindra l’état bêta. La période prévue est la fin du 2e trimestre 2024.

    • Voici les questions que je vérifie d’abord quand je découvre un nouveau langage de programmation : comment écrit-on du code asynchrone ? Y a-t-il des fonctionnalités moins mainstream comme les effets algébriques (algebraic effects), les contextes/capacités (contexts/capabilities) ou les types linéaires (linear types) ? Le système de types est-il sain, et faut-il des casts de type ? Le langage prend-il en charge les interfaces/traits/protocoles ? Jusqu’où vont les génériques ?
      Par exemple, j’aimerais vérifier s’il existe une notation explicite de la variance pour les paramètres de type, des contraintes de borne inférieure/supérieure, des types d’ordre supérieur (higher-kinded types), si le sous-typage structurel ou nominal est central, ainsi que la présence de types de données algébriques et de types de données algébriques généralisés.
      Références : https://v2.ocaml.org/manual/effects.html, https://docs.hhvm.com/hack/contexts-and-capabilities/introdu..., https://austral-lang.org/linear-types
    • Je pense que beaucoup de gens voudront en savoir plus sur la licence, le prix et le contrôle du projet. Les révéler maintenant pourrait être défavorable à la stratégie commerciale, mais le secret et l’incertitude peuvent refroidir l’intérêt.
    • La documentation https://moonbitlang.com/docs/syntax/ est difficile à lire à cause de la couleur du texte et de l’arrière-plan.
    • Je me demande si le mot-clé dédié fn est vraiment nécessaire. Je ne vois pas la différence fondamentale entre func et fn.
    • Je me demande s’il est nécessaire de distinguer func et fn, et si la flèche -> indiquant la valeur de retour dans la signature d’une fonction est vraiment indispensable.
      La syntaxe des nouveaux types est struct User, mais dans ce cas je pense que type User struct, comme en Go, serait mieux. Cela permettrait aussi de créer des types de fonction pour les variables fn, comme type AssignUser func(name: String, id: Int) -> Int.
      Je me demande aussi si : aide le lexer ou le parser. J’aimerais demander s’il ne serait pas possible d’écrire func(name String) au lieu de func(name: String) dans les signatures de fonction, et si les déclarations de type ne pourraient pas être mut elems List[int] plutôt que mut elems: List[Int]. Ce sont des pinaillages, mais dans l’ensemble j’aime bien.

  • Le site compare le langage à Rust et Go, mais pour moi la comparaison avec AssemblyScript semble plus pertinente. AssemblyScript est lui aussi natif WASM, et son écosystème encore petit lui ressemble aussi.
    Cependant, contrairement à Moonbit, c’est un langage familier pour les personnes qui ont déjà utilisé TypeScript ; je me demande donc pourquoi il faudrait utiliser Moonbit plutôt qu’AssemblyScript.

    • Parce que Moonbit est un langage moderne, tandis qu’AssemblyScript hérite d’erreurs du passé. Par exemple, Moonbit prend en charge le pattern matching et la plupart des éléments du langage sont des expressions.
      AssemblyScript n’a pas de pattern matching et se compose surtout d’instructions (statements). Moonbit a des types de données algébriques ; je ne sais pas vraiment si AssemblyScript a quelque chose de ce genre. Il peut aussi y avoir d’autres différences côté runtime, mais il est difficile d’en juger seulement à partir du site web.
    • Il semble beaucoup plus proche de Grain que d’AssemblyScript : https://grain-lang.org/.
    • La comparaison avec Rust et Go vient probablement du fait que ce sont deux langages populaires dont le support WASM est de premier ordre, mais je suis d’accord qu’il faudrait aussi le comparer à AssemblyScript.

  • Utiliser le mot-clé func pour les définitions de fonctions au niveau supérieur et fn pour les définitions de fonctions imbriquées n’est pas une bonne idée. Il faudrait unifier sur l’un des deux, indépendamment du contexte.

    • C’est peut-être parce qu’une fonction imbriquée est une closure. Contrairement aux déclarations au niveau supérieur, elle peut omettre le nom et le type, et capturer des valeurs ; il n’est donc pas rare que des langages aient une syntaxe distincte pour les closures/lambdas.
      Que ce soit vraiment nécessaire ou que ce soit une bonne conception est une autre question, mais il existe beaucoup de précédents.
    • Je trouve que c’est une conception élégante, car elle autorise une définition de fonction plus courte et plus lisible pour les fonctions imbriquées. fn permet d’omettre le nom et le type, et le mot-clé court montre que la définition de fonction peut elle aussi être plus courte.

  • Je suis enthousiaste de voir arriver un langage moderne à garbage collection ciblant WASM. Le point de comparaison le plus proche est probablement Grain : https://grain-lang.org/.

    • Il paraît que le compilateur de Grain n’est pas écrit en OCaml pur mais en ReasonML. Voir ces technologies de niche s’empiler sans complexe les unes sur les autres a quelque chose d’un peu comique.

  • « Le développement d’une toolchain complète pour un langage prenait autrefois de plusieurs années à une décennie, mais il a été simplifié grâce à l’expérience accumulée et à l’excellente équipe dédiée constituée dès les débuts de Moonbit. Moonbit devrait atteindre le statut bêta d’ici la fin du deuxième trimestre 2024, ce qui signifie une étape relativement stable, avec peu de bugs et une FFI robuste pour interagir avec les hôtes Wasm. Une fois la qualité bêta atteinte, nous publierons le code source. Stratégiquement, conformément aux propositions Wasm, nous prévoyons l’intégration de Wasm GC pour Wasm 2.0 et notre propre GC pour Wasm 1.0 »
    Donc, pour l’instant, https://github.com/moonbitlang/ est vide

  • À en juger par les commentaires ici, Moonbit semble disposer d’un garbage collection. Mais si le binaire produit pour Fibonacci fait 253 octets, il n’inclut probablement pas le GC
    Je me demande s’ils utilisent le GC natif WASM proposé, ou si le système de build est assez intelligent pour décider que le GC n’est pas nécessaire ici et l’omettre

    • En faisant un clic droit sur le fichier et en choisissant l’avant-dernier menu, Compile to Wat, on peut voir directement le texte WASM
      Dans la sortie de l’exemple Fibonacci, on ne voit que l’import print_i32, la définition de la mémoire et des fonctions, et l’export _start ; cela ne ressemble pas à un runtime GC lié au binaire
    • Il est probable qu’il l’omette intelligemment. La taille du code fait partie de leurs objectifs

  • Cela rappelle Grain. Comme c’est un autre langage de programmation pensé d’abord pour Wasm, il serait intéressant d’ajouter Grain comme point de comparaison
    https://grain-lang.org/

  • Le lien About Team mène vers une page edu.cn en chinois. Cela ressemble à un projet universitaire, mais je n’en suis pas sûr. La page Join Us est aussi en chinois, et l’exemple sur la page d’accueil semble nécessiter du JavaScript de baidu.com

    • Même avec le plugin umatrix activé, la démo fonctionne toujours. Les scripts nécessaires viennent de unpkg et de msecnd (un domaine Microsoft), pas de baidu

  • En Go, on n’implémente pas Fibonacci comme ça

    • Je n’aime pas particulièrement Go, mais il faut reconnaître que ce benchmark n’a pas de sens. Si l’on utilise des appels terminaux dans un langage qui ne prend pas en charge l’optimisation des appels terminaux, il est évident que les résultats seront mauvais
      Il était sans doute plus facile de jeter quelques chiffres que de comparer des implémentations idiomatiques et de discuter finement des compromis. Même pour un simple teaser de langage, il serait préférable d’ajouter une note sur le TCO pour éviter d’induire les gens en erreur
    • Utiliser WASM et Go dans un exemple forcé sans mentionner TinyGo ne paraît pas très honnête
    • En Rust non plus, on ne l’implémenterait pas comme ça. C’est un assez mauvais benchmark. D’après mon expérience, l’absence de récursion terminale et l’instruction switch en sont probablement la cause, et cela peut être lent en Go
      Cela reste néanmoins correct comme teaser pour présenter Moonbit

  • Je me demande si ce projet a un lien avec Meta. Son créateur, Hongbo Zhang, a travaillé chez Meta sur des projets de langages de programmation open source comme ReasonML et Flow, et d’après LinkedIn il est toujours chez Meta