1 points par GN⁺ 11 시간 전 | 1 commentaires | Partager sur WhatsApp
  • let-go est un dialecte de Clojure écrit en Go, doté d’un compilateur en bytecode et d’une VM à pile, qui fonctionne sans JVM sous la forme d’un unique binaire d’environ 10 Mo
  • Le démarrage à froid est d’environ 7 ms et la compatibilité Clojure est annoncée à 4696 / 4921 assertions réussies (95,4 %) selon la suite de tests Clojure de jank-lang
  • L’auteur l’utilise pour des CLI, des scripts et des serveurs web, a également construit un runtime de conteneurs sans daemon au-dessus de let-go, et il peut être compilé en binaire autonome ou en page web WASM autoportée
  • L’objectif est d’implémenter de nombreuses fonctionnalités de Clojure, comme les persistent data structures, les lazy seqs, les transducers, les protocols, les records, les multimethods, core.async, BigInts, ainsi qu’une interop bidirectionnelle avec les fonctions, struct et channel de Go
  • Ce n’est pas un drop-in replacement de Clojure sur JVM, il ne charge pas les JAR, et les projets réels avec des dépendances de bibliothèques nécessitent des ajustements
  • Sur un benchmark Apple M1 Pro, il affiche un binaire de 10 Mo, un temps de démarrage de 6,7 ms et une mémoire au repos de 13,5 Mo, avec un avantage mis en avant face à Babashka, Joker, go-joker, gloat et Clojure JVM pour des unités d’exécution plus petites
  • Sur des charges de calcul numérique plus importantes, le JIT WASM de go-joker ou une JVM HotSpot préchauffée restent devant ; let-go est présenté comme globalement comparable à Babashka sur la plupart des benchmarks algorithmiques, tout en étant plus de 10 fois plus rapide que Joker upstream
  • Les espaces de noms standard incluent clojure.core, clojure.string, clojure.set, clojure.edn, clojure.test, clojure.core.async, io, http, json, transit, os, System, syscall, pods, etc.
  • Il peut charger les Babashka pods, ce qui permet d’utiliser l’écosystème de pods pour SQLite, AWS, Docker, la surveillance de fichiers, etc., et partage ~/.babashka/pods/ avec bb
  • Parmi les limitations connues figurent l’absence d’implémentation de Refs / STM, Agents, hierarchies, reader tagged literals, deftype, reify, clojure.spec, alter-var-root, subseq / rsubseq, ainsi que l’absence de détection automatique des dépassements de capacité int64
  • Parmi les différences de fonctionnement, les blocs go sont de véritables goroutine et non des machines à états IOC, les regex utilisent re2 de Go au lieu des regex Java, et le système numérique est composé de int64 + float64 + BigInt
  • L’installation est possible via Homebrew pour macOS/Linux, via les Releases pour Linux, macOS et Windows en amd64/arm64, ou avec Go 1.22+ via go install github.com/nooga/let-go@latest
  • lg prend en charge le REPL, l’évaluation d’expressions et l’exécution de fichiers, ainsi que la compilation en bytecode .lgb, le bundling en exécutable autonome et la génération d’applications web WASM
  • La sortie WASM se compose d’un index.html autoporté d’environ 6 Mo gzippé avec WASM inline et d’un service worker ; lors de l’utilisation de l’espace de noms term, une émulation de terminal basée sur xterm.js est fournie
  • Le serveur nREPL intégré fonctionne avec CIDER, Calva et Conjure, et dans un programme Go, let-go peut être embarqué comme couche de scripting via pkg/api, permettant de transmettre des valeurs, fonctions, struct et channel Go à la VM

1 commentaires

 
Commentaires sur Hacker News
  • Sympa ! J’ai récemment fait une expérimentation pour superposer une syntaxe Lisp à la sémantique de Go : https://codeberg.org/veqq/Joe
    Parmi les langages de la famille Clojure sans JVM, Janet est aussi vraiment excellent, et je l’utilise en production depuis un moment : https://janet-lang.org/
    Si on veut une VM Lua et ses bibliothèques, il y a aussi Fennel

    • Joe a l’air pas mal. Je n’ai pas encore essayé Janet moi-même, mais j’ai l’impression que c’est un langage qui suit sa propre voie plutôt que d’essayer d’imiter Clojure
  • Ce REPL Wasm dans le navigateur vaut aussi le détour : https://gloathub.org/repl/
    Gloat est un outil d’automatisation AOT pour Glojure
    L’été dernier, j’ai travaillé avec James Hamlin pour rendre possible l’AOT de Glojure, et je continue depuis à le faire progresser. Je travaille aussi avec marcingas(nooga) pour que Gloat/Glojure/let-go coopèrent bien entre eux

  • Étonnant que ça tourne sur Plan 9
    Ce serait chouette que Go devienne un langage de premier rang sur 9front, c’est-à-dire inclus par défaut
    Je bricole un réseau social pour Plan 9 : https://youtube.com/watch?v=q6qVnlCjcAI&si=MBCeM0QdA0WsKAe7
    Tout est fait en rc et awk, mais à certains endroits, j’aurais bien aimé avoir un peu de Go ou de Clojure au milieu

    • J’aime bien la démo de 9social. Je n’utilise pas Plan 9 moi-même, mais je trouve toujours de l’inspiration dans la manière de faire propre à Plan 9
    • J’ai commencé à distribuer dans les releases GitHub des binaires amd64 et arm 32 bits pour Plan 9
      amd64 a été testé sur 9front et tout semble bien fonctionner. Le CLI n’a pas encore vraiment une allure Plan 9, mais j’aimerais à terme rendre le port plus natif
  • Maintenant qu’il existe plusieurs dialectes Go de Clojure, ce que j’aimerais surtout savoir, c’est lequel est entièrement hébergé sur Go et offre un niveau d’interopérabilité comparable à celui qu’a Clojure JVM avec Java
    J’aimerais pouvoir utiliser en Go ce que je crée, utiliser Go depuis Clojure, et même monter des projets mixtes. Et au-delà de l’interopérabilité, ce serait bien d’avoir un récapitulatif précis de ce qui reste identique et de ce qui diffère

    • Gloat/Glojure semble avoir le meilleur argument côté runtime hébergé grâce à son pipeline AOT vers du code source Go. On peut importer n’importe quel élément de Go au moment de la compilation
      En revanche, let-go peut faire des allers-retours avec n’importe quelle valeur Go, y compris des structures, des fonctions et des canaux, mais il ne peut pas faire venir directement une bibliothèque Go arbitraire sans wrapper. Ces bibliothèques doivent être construites dans le runtime
  • Petite remarque, mais le README parle d’un cold start à 7 ms, puis quelques lignes plus bas de 6 ms. Peut-être qu’il devient plus rapide à mesure qu’on lit le README

    • Corrigé. Sur ma machine, c’est 6 à 7 ms, et la médiane semble tourner autour de 6,5 ms
  • C’est exactement le genre de portage de Clojure que j’attendais depuis longtemps
    Je trouvais que la bibliothèque standard de Go et l’abstraction des canaux constituaient une API de base plus simple et plus solide, et que ça irait bien avec une API du style core.async. Ça répond aussi au besoin d’un gros binaire monolithique
    Merci pour le travail, et dès que mon nouvel engouement pour C++26 retombera un peu, j’irai regarder ça de plus près
    En plus, je ne sais pas pourquoi Glojure n’était pas sur mon radar, parce que ça aussi a l’air d’être un excellent projet

    • J’ai déjà réfléchi à l’idée de créer une DSL à l’ancienne façon PHP qui exploiterait en interne le runtime et les packages de Go
      Si je dis ancien PHP, c’est parce qu’au départ PHP ressemblait davantage à une DSL centrée sur le web ; ce n’est plus vraiment le cas aujourd’hui. Un langage backend facile à écrire, un peu à la PHP, mais propulsé par Go, pourrait être intéressant, et Clojure serait un très bon choix
    • Si tu l’essaies vraiment plus tard, ce serait super que tu laisses un ou deux tickets
  • Comme alternative, il y a aussi Joker : https://joker-lang.org
    C’est vraiment excellent, mais je trouve que c’est complètement sous-estimé

    • Ce que j’apprécie beaucoup dans Joker, c’est à quel point le wrapping des bibliothèques Go est fluide. On dirait qu’il couvre tout ce que Go propose
      Cela dit, je ne veux pas trop en ajouter à let-go. J’aime bien le fait qu’il tienne dans 10 Mo
  • J’aimerais que le nom du langage soit meilleur que simplement « lets-go ». Que diriez-vous de « clogo » ?

    • Trouver un nom est difficile, mais let-go me plaît bien. C’est un jeu de mots à plusieurs niveaux
      (let [...] (go ...))
      Ça permet de faire du let en Go !
      Clogo, pour moi, c’est no-go. Mais s’il y a d’autres idées, je suis prêt à examiner les bonnes propositions
  • Une PR sur https://github.com/chr15m/awesome-clojure-likes serait très bienvenue