Scheme, das in WebAssembly läuft — das Hoot-Projekt

• Ein Projekt, das dafür entwickelt wurde, Scheme-Code in WebAssembly (Browser mit GC-Unterstützung) auszuführen, und das einen Scheme→Wasm-Compiler sowie eine vollständige Wasm-Toolchain umfasst
• Basiert auf GNU Guile, kommt ohne zusätzliche Abhängigkeiten aus und besitzt eine eigenständige (self-contained) Toolchain
• In der Guile-REPL-Umgebung können Hoot-Binärdateien über den Wasm-Interpreter getestet werden
• Die aktuelle Version ist v0.7.0; Links zu Release-Dateien, Signaturen, Dokumentation und offizieller Ankündigung werden bereitgestellt
• Ein Versuch, die Sprache Scheme in die Web-Umgebung zu erweitern, der das Potenzial für den Ausbau eines browserbasierten Lisp-Ökosystems zeigt

---

Überblick über Hoot

• Hoot ist ein von Spritely Institute entwickeltes Projekt, das Scheme-Code auf WebAssembly (Wasm) lauffähig macht
  • Läuft in Webbrowsern, die GC- (Garbage Collection-) Funktionen unterstützen
  • Enthält einen Compiler, der Scheme-Code in Wasm umwandelt, sowie eine vollständige Toolchain für die Wasm-bezogene Entwicklung
• Es ist auf Guile aufgebaut und hat keine zusätzlichen externen Abhängigkeiten
  • Die Toolchain ist in sich vollständig und enthält einen Wasm-Interpreter, sodass Hoot-Binärdateien direkt in der Guile-REPL getestet werden können

Veröffentlichung und Entwicklung

• Das neueste Release ist Version v0.7.0; Download-Dateien, Signaturen, Dokumentation und ein Link zur offiziellen Ankündigung werden bereitgestellt
  • Release-Datei: guile-hoot-0.7.0.tar.gz
  • Dokumentation, Signaturdateien und eine zugehörige News-Seite sind ebenfalls verfügbar
• Auf die Entwicklungsversion kann über das Codeberg-Repository zugegriffen werden (https://codeberg.org/spritely/hoot)

Weiterführende Materialien

• Es werden mehrere Beiträge zu interaktiven Webseiten mit Hoot und zur Ausführung von Scheme im Browser bereitgestellt
  • “Building interactive web pages with Hoot”
  • “Scheme in the browser: A Hoot of a tale”
  • “Lisp Game Jam - ‘Wireworld’ - Hoot's low level Wasm tooling in action”
• Zusätzliche Informationen aus Entwicklerperspektive finden sich im Blog von Andy Wingo und im Interview-Video von System Crafters

[GN⁺]

Hacker-News-Kommentare

• Es ist interessant, dass die Entwicklung von Guile in letzter Zeit wieder an Fahrt aufnimmt.
  Gleichzeitig ist es etwas schade, dass offenbar viele Leute aus der früheren Racket-Community dorthin wechseln.
  Wenn sich eine Community aufspaltet, ist das traurig, und Guile wirkt im Vergleich zu Racket bei Performance und Vielfalt der Bibliotheken immer noch etwas im Hintertreffen.

  • Nach meiner Erfahrung war es eher umgekehrt. Guile startet schneller als Racket, und da meine Arbeit größtenteils I/O-lastig ist, war Guile für mich die bessere Wahl.
    Benchmarks können etwas anderes zeigen, aber man sollte es wohl selbst ausprobieren.
  • Guile hat derzeit eine Architektur aus Bytecode-VM + JIT, ist also langsamer als Chez/Racket, aber dennoch ziemlich schnell.
    Es ist schnell genug, um Spiele mit 60 fps laufen zu lassen, und GC tritt auch nur selten auf.
    Auch das Bibliotheks-Ökosystem ist deutlich besser geworden als früher.
  • Ich erinnere mich, früher einen Blogbeitrag über ein „Missing Stair“-Problem in der Racket-Community gelesen zu haben.
    (Missing-Stair-Wiki)
    Dass sich die Community nach diesem Vorfall gespalten hat, wirkt wie eine unvermeidliche Folge.
  • Es ist schön, dass Guile Aufmerksamkeit bekommt, aber man sollte Racket nicht unterschätzen.
    • Guiles WASM-Arbeit ist vielversprechend, und auf der Racket-Seite entwickelt Jens Axel Soegaard ebenfalls einen entsprechenden Compiler.
    • Rackets Rehosting auf Chez-Basis scheint eine gute Entscheidung zu sein, und die interne Struktur dürfte dadurch auch leichter handhabbar geworden sein als die von Guile.
    • Racket hat weiterhin seine Stärken bei Metaprogrammierung und dem Modulsystem.
      Zum Beispiel kann man mit Overeasy Tests schreiben und mit McFly Dokumentation inline verfassen.
    • Scheme-Sprachen bleiben weiterhin etwas für Leute, die sich nicht um „Stichwörter für den Arbeitsmarkt“ kümmern müssen.
      Die schwierigere Stimmung in der Branche nach dem jüngsten AI-Code-Generation-Boom und dem Zusammenbruch von VC-Investitionen spielt dabei wohl auch eine Rolle.
  • Ich frage mich, ob schon einmal Benchmarks für Hoot, eine andere Implementierung von Guile (zum Beispiel auf V8), gemacht wurden.

• Das Projekt selbst ist cool, aber ich hätte mir gewünscht, dass dafür eine andere Sprache als Guile verwendet wird.

  • Trotzdem ist Guile die Sprache von Guix, weshalb das Ökosystem reichhaltig ist.
    Über Guix lassen sich leicht reproduzierbare Builds erstellen.
    Allerdings gibt es weiterhin Probleme mit dem Debugger, dem Macro Expander und den R6RS-Standardbibliotheken.
    Die Multicore-Unterstützung von Racket war früher schwergewichtig, scheint sich inzwischen aber im Vergleich zu Guiles fibers/futures verbessert zu haben.
  • Falls damit gemeint ist, statt Guile eine andere Scheme-Implementierung zu nutzen: Wenn man R6RS/R7RS-Standardsyntax verwendet, ist die Portierung nicht besonders schwierig.

• Es ist schön zu sehen, dass solche Versuche, nach WASM zu kompilieren, wieder auftauchen.
  Ich dachte schon, die Begeisterung dafür sei abgeflaut, aber wenn es mehr solcher Sprachen gibt, ist das gut, weil man dann JavaScript vermeiden kann.

• Dieses Projekt bringt mich dazu, über die zukünftige Richtung von Programmiersprachen nachzudenken.
  Wenn AI der Hauptautor von Code wird, werden sich Sprachen wohl stärker auf Klarheit und Fehlervermeidung ausrichten.
  Für Menschen ist das vielleicht weniger spannend, aber der Code wird sich leichter korrigieren lassen.
  In diesem Kontext dürften Sprachen wie Rust weit oben landen.
  Ich frage mich allerdings, ob eine Sprache wie Hoot auch in spezialisierten Bereichen ihren Platz finden kann oder ob sie eine Hobby-Sprache bleibt.

  • Ich habe mich auch gefragt, wie eine AI-zentrierte Sprache aussehen könnte, und ich denke, dass Scheme-/Lisp-Sprachen dieser Richtung wohl recht nahekommen.

• Wirklich großartig! Ich frage mich, ob das vielleicht auch auf Cloudflare Workers laufen könnte.

• Ich wünschte, Guile hätte eine etwas bessere Windows-Unterstützung.

• repl.wasm ist mit 1.6 MiB etwas groß. Ich frage mich, wie groß das todo-Beispiel ist.

  • Dieses REPL ist nicht die kleinste mögliche Binärdatei, aber mit gzip-Komprimierung schrumpft es auf 339K.
    wasm-opt-Optimierungen wurden noch gar nicht angewendet.
    Hoot ist ein AOT-Compiler, daher enthält das REPL zusätzlichen Code wie den Macro Expander, das Laufzeit-Modulsystem, den Interpreter usw.
    Das tatsächliche Beispiel todo.wasm ist etwa 566K groß (komprimiert 143K) und enthält außerdem einen virtuellen-DOM-Diff-Algorithmus.
    Mit weiteren Optimierungen, etwa durch das Reduzieren der Anzahl lokaler Variablen oder die Übernahme des Stack-Switching-Vorschlags, dürfte sich die Größe noch weiter senken lassen.
    Das zugehörige Issue ist hier zusammengefasst.

• woot

• Genau so hatte JavaScript ursprünglich einmal gedacht werden sollen.
  Wenn Netscape nicht auf einer Syntax im Stil von C/Java bestanden hätte, wäre vielleicht so eine Sprache daraus geworden.