2 poin oleh GN⁺ 2026-02-09 | 1 komentar | Bagikan ke WhatsApp
  • Proyek yang dirancang agar kode Scheme dapat dijalankan di WebAssembly(browser dengan dukungan GC), mencakup kompiler Scheme→Wasm dan toolchain Wasm yang lengkap
  • Dibangun di atas GNU Guile, tanpa dependensi tambahan, dengan struktur mandiri(toolchain self-contained)
  • Di lingkungan Guile REPL, pengujian biner Hoot melalui interpreter Wasm dimungkinkan
  • Versi terbaru adalah v0.7.0, dan tersedia tautan ke berkas rilis, tanda tangan, dokumentasi, serta pengumuman resmi
  • Sebagai upaya memperluas bahasa Scheme ke lingkungan web, proyek ini menunjukkan potensi perluasan ekosistem Lisp berbasis browser

Ikhtisar Hoot

  • Hoot adalah proyek yang dikembangkan oleh Spritely Institute untuk menjalankan kode Scheme di atas WebAssembly(Wasm)
    • Berjalan di browser web yang mendukung fitur GC(Garbage Collection)
    • Mencakup kompiler yang mengubah kode Scheme menjadi Wasm, serta toolchain lengkap untuk pengembangan terkait Wasm
  • Dibangun di atas Guile dan tidak memiliki dependensi eksternal tambahan
    • Toolchain-nya lengkap secara mandiri dan menyertakan interpreter Wasm, sehingga biner Hoot dapat diuji langsung dari Guile REPL

Distribusi dan pengembangan

  • Rilis terbaru adalah versi v0.7.0, dengan tautan ke berkas unduhan, tanda tangan, dokumentasi, dan pengumuman resmi
    • Berkas rilis: guile-hoot-0.7.0.tar.gz
    • Berkas dokumentasi dan tanda tangan, serta halaman berita terkait juga disediakan
  • Versi pengembangan dapat diakses di repositori Codeberg (https://codeberg.org/spritely/hoot)

Materi terkait

  • Tersedia sejumlah artikel tentang contoh pembuatan halaman web interaktif dengan Hoot dan menjalankan Scheme di dalam browser
    • “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”
  • Informasi tambahan dari sudut pandang pengembang tersedia melalui blog Andy Wingo dan video wawancara System Crafters

1 komentar

 
GN⁺ 2026-02-09
Komentar Hacker News
  • Menarik melihat pengembangan Guile belakangan ini semakin aktif
    Namun agak disayangkan karena tampaknya banyak orang dari komunitas Racket lama yang pindah ke sana
    Sedih melihat komunitas terpecah, dan Guile masih terasa tertinggal dibanding Racket dalam hal performa maupun keragaman pustaka

    • Dalam pengalaman saya justru sebaliknya. Guile punya kecepatan startup yang lebih baik daripada Racket, dan karena sebagian besar pekerjaan saya berbasis I/O, Guile lebih cocok
      Hasil benchmark mungkin berbeda, tapi sepertinya memang perlu dicek langsung
    • Guile saat ini memakai arsitektur bytecode VM + JIT, jadi memang lebih lambat daripada Chez/Racket, tapi tetap cukup cepat
      Cukup untuk menjalankan game di 60fps, dan GC juga jarang terjadi
      Ekosistem pustaka-nya juga sudah jauh membaik dibanding dulu
    • Saya ingat pernah membaca tulisan blog tentang adanya masalah “Missing Stair” di komunitas Racket dulu
      (wiki Missing Stair)
      Setelah kejadian itu, perpecahan komunitas tampak seperti hasil yang sulit dihindari
    • Senang Guile mendapat perhatian, tapi rasanya tidak adil jika jadi meremehkan Racket
      • Pekerjaan WASM di Guile menjanjikan, dan di pihak Racket Jens Axel Soegaard juga sedang mengembangkan compiler terkait
      • Rehosting berbasis Chez pada Racket tampak seperti pilihan yang bagus, dan struktur internalnya mungkin sekarang lebih mudah ditangani daripada Guile
      • Racket masih unggul dalam metaprogramming dan sistem modul
        Misalnya, dengan Overeasy untuk testing, dan McFly untuk menulis dokumentasi secara inline
      • Keluarga Scheme tetap menjadi bahasa untuk orang-orang yang tidak perlu terlalu memikirkan “kata kunci untuk cari kerja”
        Suasana industri belakangan juga makin sulit setelah AI code generation dan runtuhnya investasi VC
    • Saya penasaran apakah implementasi Guile lain seperti Hoot (misalnya berjalan di atas V8) pernah dibenchmark
  • Proyeknya sendiri keren, tapi saya agak berharap bahasa yang dipakai bukan Guile

    • Meski begitu, Guile adalah bahasa dari Guix, jadi ekosistemnya kaya
      Melalui Guix, kita bisa dengan mudah membuat build yang reproducible
      Tapi masalah terkait debugger, macro expander, dan pustaka standar R6RS masih tetap ada
      Dukungan multicore di Racket dulu terasa berat, tetapi sekarang tampaknya sudah membaik jika dibandingkan dengan fibers/futures di Guile
    • Kalau maksudnya memakai implementasi Scheme selain Guile, memakai sintaks standar R6RS/R7RS membuat porting tidak terlalu sulit
  • Senang melihat upaya seperti ini untuk compile ke WASM kembali muncul
    Dulu saya kira antusiasmenya sudah mereda, tapi kalau bahasa-bahasa seperti ini makin banyak, itu bagus karena bisa menghindari JavaScript

  • Proyek ini membuat saya memikirkan lagi arah bahasa pemrograman di masa depan
    Jika AI menjadi penulis kode utama, bahasa mungkin akan bergeser untuk menekankan kejelasan dan pengurangan kesalahan
    Kodenya mungkin jadi kurang menyenangkan bagi manusia, tetapi lebih mudah diperbaiki
    Dalam konteks itu, bahasa seperti Rust tampaknya akan berada di posisi atas
    Tapi saya penasaran apakah bahasa seperti Hoot bisa mendapat tempat bahkan di ranah profesional, atau akan tetap menjadi bahasa hobi

    • Saya juga penasaran seperti apa bahasa yang berpusat pada AI, dan rasanya keluarga Scheme/Lisp justru cukup dekat ke arah itu
  • Keren sekali! Apakah ini juga bisa berjalan di Cloudflare Workers?

  • Saya harap Guile bisa memberi dukungan Windows yang lebih baik

  • repl.wasm berukuran 1.6MiB, jadi terasa agak besar. Saya penasaran berapa ukuran contoh todo

    • REPL ini memang bukan biner yang paling kecil, tetapi dengan kompresi gzip ukurannya turun menjadi 339K
      wasm-opt juga masih belum diterapkan
      Hoot adalah compiler AOT, jadi pada REPL ada kode tambahan seperti macro expander, sistem modul runtime, interpreter, dan lainnya
      Contoh nyata todo.wasm berukuran sekitar 566K (143K setelah dikompresi), dan itu juga mencakup algoritma diff virtual DOM
      Dengan optimasi tambahan seperti mengurangi jumlah variabel lokal, atau mengadopsi proposal stack switching, ukurannya diharapkan bisa diperkecil lagi
      Isu terkait dirangkum di sini
  • woot

  • Inilah sebenarnya bentuk yang dulu ingin dituju oleh JavaScript
    Kalau Netscape tidak memaksakan sintaks bergaya C/Java, mungkin hasilnya akan menjadi bahasa seperti ini