WebAssembly में चलने वाला Scheme — Hoot प्रोजेक्ट

• Scheme कोड को WebAssembly (GC सपोर्ट वाले ब्राउज़र) में चलाने के लिए डिज़ाइन किया गया प्रोजेक्ट, जिसमें Scheme→Wasm compiler और पूरा Wasm toolchain शामिल है
• यह GNU Guile आधारित है, इसमें कोई अतिरिक्त dependency नहीं है, और इसकी संरचना self-contained toolchain की है
• Guile REPL वातावरण में Wasm interpreter के ज़रिए Hoot binary का टेस्ट किया जा सकता है
• नवीनतम संस्करण v0.7.0 है, और release files, signatures, documentation, तथा official announcement links उपलब्ध हैं
• यह Scheme भाषा को web environment तक विस्तारित करने का प्रयास है, जो browser-based Lisp ecosystem के विस्तार की संभावना दिखाता है

---

Hoot का अवलोकन

• Hoot, Spritely Institute द्वारा विकसित प्रोजेक्ट है, जो Scheme कोड को WebAssembly (Wasm) पर चलाने योग्य बनाता है
  • यह GC (Garbage Collection) फीचर सपोर्ट करने वाले web browsers में काम करता है
  • इसमें Scheme कोड को Wasm में बदलने वाला compiler और Wasm-संबंधित development के लिए पूरा toolchain शामिल है
• यह Guile के ऊपर बनाया गया है और इसमें कोई अतिरिक्त external dependency नहीं है
  • toolchain अपने आप में पूर्ण है, और इसमें Wasm interpreter built-in है, जिससे Guile REPL में Hoot binary को सीधे test किया जा सकता है

वितरण और विकास

• नवीनतम release v0.7.0 संस्करण है, जिसमें download files, signatures, documentation, और official announcement links दिए गए हैं
  • release file: guile-hoot-0.7.0.tar.gz
  • documentation और signature files, साथ ही संबंधित news page भी उपलब्ध है
• development version Codeberg repository पर उपलब्ध है (https://codeberg.org/spritely/hoot)

संबंधित सामग्री

• Hoot का उपयोग करके interactive web pages बनाना और browser में Scheme चलाने से जुड़े कई लेख उपलब्ध हैं
  • “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”
• Andy Wingo के ब्लॉग और System Crafters interview video के ज़रिए developer दृष्टिकोण से अतिरिक्त जानकारी देखी जा सकती है

[GN⁺]

Hacker News टिप्पणियाँ

• हाल में Guile का विकास तेज़ी से सक्रिय होना दिलचस्प है
  लेकिन यह थोड़ा अफसोसजनक भी लगता है कि पुराने Racket कम्युनिटी के बहुत से लोग उधर जा रहे हैं
  कम्युनिटी का बँट जाना दुखद है, और Guile अब भी performance और library diversity के मामले में Racket से पीछे लगता है

  • मेरे अनुभव में तो इसका उल्टा था। Guile, Racket से startup speed में तेज़ था, और मेरा ज़्यादातर काम I/O-केंद्रित होता है इसलिए Guile मेरे लिए बेहतर रहा
    benchmarks कुछ और कह सकते हैं, लेकिन इसे खुद जाँचने की ज़रूरत होगी
  • Guile अभी bytecode VM + JIT संरचना पर है, इसलिए Chez/Racket से धीमा है लेकिन फिर भी काफ़ी तेज़ है
    इतना कि 60fps पर गेम चला सकता है, और GC भी कम ही होता है
    पहले की तुलना में library ecosystem भी काफ़ी बेहतर हुआ है
  • याद है कि पहले Racket कम्युनिटी में ‘Missing Stair’ समस्या पर एक ब्लॉग पोस्ट देखी थी
    (Missing Stair wiki)
    उस घटना के बाद कम्युनिटी का बँटना एक तरह से अपरिहार्य नतीजा लगता है
  • Guile पर ध्यान जाना अच्छा है, लेकिन Racket को कम करके आँकना सही नहीं होगा
    • Guile का WASM काम उम्मीद जगाता है, और Racket पक्ष में Jens Axel Soegaard भी संबंधित compiler बना रहे हैं
    • Racket का Chez-आधारित rehosting अच्छा निर्णय लगता है, और इसकी अंदरूनी संरचना भी शायद Guile से ज़्यादा संभालने योग्य हो गई होगी
    • Racket की ताकत अब भी metaprogramming और module system हैं
      उदाहरण के लिए Overeasy से tests, और McFly से inline documentation लिखी जा सकती है
    • Scheme परिवार अब भी उन लोगों की भाषा बना हुआ है जिन्हें “रोज़गार कीवर्ड” की ज़्यादा चिंता नहीं करनी पड़ती
      हाल की AI code generation और VC investment collapse के बाद इंडस्ट्री का माहौल और कठिन हुआ है
  • जिज्ञासा है कि Guile के दूसरे implementation Hoot (जैसे V8 पर चलने वाला) का कभी benchmark किया गया है या नहीं

• प्रोजेक्ट खुद बहुत बढ़िया है, लेकिन मन में आता है कि काश Guile की जगह कोई और भाषा इस्तेमाल की गई होती

  • फिर भी Guile, Guix की भाषा है, इसलिए इसका ecosystem समृद्ध है
    Guix के ज़रिए reproducible builds आसानी से बनाए जा सकते हैं
    लेकिन debugger, macro expander, और R6RS standard library से जुड़ी समस्याएँ अब भी बाकी हैं
    Racket का multicore support पहले भारी था, लेकिन Guile के fibers/futures की तुलना में अब शायद बेहतर हो गया है
  • अगर बात Guile की बजाय कोई दूसरी Scheme implementation इस्तेमाल करने की है, तो R6RS/R7RS standard syntax का उपयोग करने पर portability मुश्किल नहीं होगी

• WASM में compile करने की ऐसी कोशिशें फिर से देखना अच्छा लग रहा है
  पहले लगा था कि इसका उत्साह ठंडा पड़ गया है, लेकिन अगर ऐसी भाषाएँ बढ़ें तो JavaScript से बचा जा सकेगा, जो अच्छी बात है

• इस प्रोजेक्ट को देखकर भविष्य की programming language direction के बारे में सोचने लगा
  अगर AI मुख्य code writer बन जाए, तो भाषाएँ शायद clarity और error reduction पर केंद्रित हो जाएँगी
  इंसानों के लिए वे कम मज़ेदार होंगी, लेकिन संशोधित करना आसान होगा
  इस संदर्भ में Rust जैसी भाषाएँ ऊपर आएँगी
  लेकिन जिज्ञासा है कि Hoot जैसी भाषा विशेषज्ञ क्षेत्रों में भी जगह बना पाएगी, या फिर hobby language बनकर रह जाएगी

  • मैं भी सोच रहा था कि AI-केंद्रित language कैसी दिखेगी, और शायद Scheme/Lisp परिवार उस दिशा के ज़्यादा क़रीब है

• सच में शानदार! क्या यह Cloudflare Workers पर भी चल सकता है?

• काश Guile का Windows support थोड़ा बेहतर होता

• repl.wasm 1.6MiB है, तो थोड़ा बड़ा लगता है। todo उदाहरण कितना बड़ा है, यह जानना है

  • यह REPL सबसे छोटा binary नहीं है, लेकिन gzip compression के बाद 339K तक घट जाता है
    अभी wasm-opt optimization भी लागू नहीं हुआ है
    Hoot एक AOT compiler है, इसलिए REPL में macro expander, runtime module system, interpreter आदि का अतिरिक्त code शामिल है
    वास्तविक उदाहरण todo.wasm लगभग 566K (compression के बाद 143K) है, और इसमें virtual DOM diff algorithm भी शामिल है
    आगे और optimization करके local variables की संख्या घटाई जा सकती है, या stack switching proposal अपनाने पर आकार और कम हो सकता है
    संबंधित issue यहाँ संक्षेप में दिया गया है

• woot (छोटी विस्मयाभिव्यक्ति)

• यही वह रूप था जिसकी ओर JavaScript मूल रूप से जाना चाहता था
  अगर Netscape ने C/Java-शैली syntax पर ज़ोर न दिया होता, तो शायद यह ऐसी भाषा बनती