Scheme ที่รันบน WebAssembly — โปรเจกต์ Hoot

 (spritely.institute)
2 คะแนน โดย GN⁺ 2026-02-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โปรเจกต์ที่ออกแบบมาเพื่อให้รันโค้ด Scheme บน WebAssembly (เบราว์เซอร์ที่รองรับ GC) โดยมีทั้ง คอมไพเลอร์ Scheme→Wasm และทูลเชน Wasm แบบครบชุด
  • สร้างขึ้นบนพื้นฐานของ GNU Guile ไม่มีการพึ่งพาเพิ่มเติม และมีโครงสร้างแบบ พึ่งพาตนเอง (toolchain self-contained)
  • สามารถทดสอบไบนารีของ Hoot ผ่าน Wasm interpreter ในสภาพแวดล้อม Guile REPL ได้
  • เวอร์ชันล่าสุดคือ v0.7.0 พร้อมลิงก์ไฟล์รีลีส ลายเซ็น เอกสาร และประกาศอย่างเป็นทางการ
  • เป็นความพยายามในการขยายภาษา Scheme ไปสู่สภาพแวดล้อมเว็บ และแสดงให้เห็นถึง ความเป็นไปได้ในการขยายระบบนิเวศ Lisp บนเบราว์เซอร์

ภาพรวมของ Hoot

  • Hoot เป็นโปรเจกต์ที่พัฒนาโดย Spritely Institute เพื่อให้สามารถรัน โค้ด Scheme บน WebAssembly (Wasm) ได้
    • ทำงานบนเว็บเบราว์เซอร์ที่รองรับความสามารถ GC (Garbage Collection)
    • มีทั้ง คอมไพเลอร์ สำหรับแปลงโค้ด Scheme เป็น Wasm และ ทูลเชนแบบครบชุด สำหรับการพัฒนาที่เกี่ยวข้องกับ Wasm
  • สร้างขึ้นบน Guile และไม่มีการพึ่งพาภายนอกเพิ่มเติม
    • ทูลเชนมีความสมบูรณ์ในตัวเอง และมี Wasm interpreter ในตัว ทำให้สามารถทดสอบไบนารีของ Hoot ได้โดยตรงใน Guile REPL

การเผยแพร่และการพัฒนา

  • รีลีสล่าสุดคือเวอร์ชัน v0.7.0 โดยมีลิงก์ไฟล์ดาวน์โหลด ลายเซ็น เอกสาร และประกาศอย่างเป็นทางการ
    • ไฟล์รีลีส: guile-hoot-0.7.0.tar.gz
    • มีทั้งเอกสาร ไฟล์ลายเซ็น และหน้าข่าวที่เกี่ยวข้องให้พร้อม
  • เวอร์ชันพัฒนาสามารถเข้าถึงได้จากรีโพซิทอรีบน Codeberg (https://codeberg.org/spritely/hoot)

แหล่งข้อมูลที่เกี่ยวข้อง

  • มีตัวอย่างการใช้งาน Hoot สำหรับ การสร้างเว็บเพจแบบโต้ตอบ และบทความหลายชิ้นเกี่ยวกับ การรัน 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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-09
ความคิดเห็นบน Hacker News

  • น่าสนใจที่ช่วงนี้การพัฒนาของ Guile กลับมาคึกคักอีกครั้ง
    แต่ก็แอบเสียดายที่ดูเหมือนคนจากคอมมูนิตี้ Racket เดิมย้ายกันมาเยอะ
    การที่คอมมูนิตี้แยกออกจากกันเป็นเรื่องน่าเศร้า และ Guile ก็ยังให้ความรู้สึกว่าตามหลัง Racket อยู่ทั้งด้านประสิทธิภาพและความหลากหลายของไลบรารี

    • จากประสบการณ์ของฉันกลับตรงกันข้ามเลย Guile เปิดตัวได้เร็วกว่า Racket และงานที่ฉันทำส่วนใหญ่เป็นแบบเน้น I/O เลยรู้สึกว่า Guile ดีกว่า
      ผลเบนช์มาร์กอาจออกมาต่างกัน แต่ก็คงต้องลองเช็กกันเอง
    • ตอนนี้ Guile ใช้โครงสร้าง bytecode VM + JIT เลยยังช้ากว่า Chez/Racket แต่ก็ถือว่าเร็วพอตัว
      เร็วพอจะรันเกมที่ 60fps ได้ และ GC ก็เกิดไม่บ่อย
      ecosystem ของไลบรารีก็ดีขึ้นมากเมื่อเทียบกับแต่ก่อน
    • จำได้ว่าเคยเห็นบล็อกโพสต์เกี่ยวกับปัญหา ‘Missing Stair’ ในคอมมูนิตี้ Racket
      (วิกิ Missing Stair)
      หลังเหตุการณ์นั้น คอมมูนิตี้จะแตกออกเป็นหลายส่วนก็ดูเป็นผลลัพธ์ที่หลีกเลี่ยงไม่ได้
    • ดีใจที่ Guile ได้รับความสนใจมากขึ้น แต่ก็ไม่ควรมองข้ามคุณค่าของ Racket
      • งานด้าน WASM ของ Guile ดูมีอนาคต และฝั่ง Racket เอง Jens Axel Soegaard ก็กำลังพัฒนาคอมไพเลอร์ที่เกี่ยวข้องอยู่
      • การ rehost บนฐาน Chez ของ Racket ดูเป็นทางเลือกที่ดี และน่าจะทำให้โครงสร้างภายในจัดการได้ง่ายกว่า Guile ด้วย
      • Racket ยังเด่นมากในเรื่องmetaprogrammingและmodule system
        ตัวอย่างเช่น ใช้ Overeasy สำหรับเทสต์ และ McFly เพื่อเขียนเอกสารแบบ inline ได้
      • สาย Scheme ก็ยังคงเป็นภาษาของคนที่ไม่จำเป็นต้องกังวลเรื่อง “คีย์เวิร์ดหางาน”
        บรรยากาศในอุตสาหกรรมที่ยากขึ้นหลังยุค AI สร้างโค้ด และ การล่มสลายของเงินทุน VC ก็น่าจะมีผลด้วย
    • สงสัยว่า Hoot ซึ่งเป็นอีก implementation ของ Guile (เช่น แบบที่ทำงานบน V8) เคยมีการทำเบนช์มาร์กไว้บ้างหรือยัง

  • ตัวโปรเจ็กต์เองเจ๋งมาก แต่ก็อดคิดไม่ได้ว่าถ้าใช้ภาษาอื่นที่ไม่ใช่ Guile อาจจะดีกว่า

    • ถึงอย่างนั้น Guile ก็เป็นภาษาของ Guix อยู่แล้ว เลยมี ecosystem ที่ค่อนข้างอุดมสมบูรณ์
      และยังใช้ Guix เพื่อทำ reproducible build ได้ง่าย
      แต่ปัญหาเรื่อง debugger, macro expander, และ ไลบรารีมาตรฐาน R6RS ก็ยังมีอยู่
      การรองรับมัลติคอร์ของ Racket เมื่อก่อนค่อนข้างหนัก แต่ตอนนี้ดูเหมือนจะดีขึ้นเมื่อเทียบกับ fibers/futures ของ Guile
    • ถ้าหมายถึงให้ใช้ Scheme implementation ตัวอื่นแทน Guile แค่เขียนตามไวยากรณ์มาตรฐาน R6RS/R7RS ก็ไม่น่าจะย้ายได้ยาก

  • ดีใจที่ได้เห็นความพยายามแบบนี้ในการ คอมไพล์เป็น WASM กลับมาอีก
    ก่อนหน้านี้นึกว่ากระแสซาไปแล้ว แต่ถ้ามีภาษาแบบนี้มากขึ้นก็ดี เพราะจะได้หลีกเลี่ยง JavaScript

  • โปรเจ็กต์นี้ทำให้นึกถึงทิศทางของภาษาโปรแกรมในอนาคต
    ถ้า AI กลายเป็นผู้เขียนโค้ดหลัก ภาษาอาจเปลี่ยนไปเน้นที่ความชัดเจนและการลดข้อผิดพลาดมากขึ้น
    มันอาจจะสนุกน้อยลงสำหรับมนุษย์ แต่จะเป็นโค้ดที่แก้ไขได้ง่ายกว่า
    ในบริบทนี้ ภาษาตระกูลอย่าง Rust น่าจะขึ้นมาอยู่แถวบน ๆ
    แต่ก็ยังสงสัยว่า ภาษาอย่าง Hoot จะไปยืนในสายงานเฉพาะทางได้ไหม หรือสุดท้ายจะเป็นแค่ภาษางานอดิเรก

    • ฉันก็เคยสงสัยเหมือนกันว่าภาษาที่ออกแบบมาเพื่อ AI เป็นศูนย์กลาง จะหน้าตาเป็นยังไง แต่คิดว่าอาจจะใกล้กับสาย Scheme/Lisp มากที่สุด

  • เจ๋งมาก! สงสัยว่าจะรันบน Cloudflare Workers ได้ไหม

  • อยากให้ Guile รองรับ Windows ได้ดีกว่านี้หน่อย

  • repl.wasm ขนาด 1.6MiB ดูจะใหญ่ไปนิด อยากรู้ว่าตัวอย่าง todo จะขนาดเท่าไร

    • REPL นี้ไม่ใช่ไบนารีที่เล็กที่สุด แต่ถ้าบีบอัดด้วย gzip จะเหลือ 339K
      และยังไม่ได้ใช้การปรับแต่งด้วย wasm-opt เลย
      Hoot เป็น คอมไพเลอร์แบบ AOT ดังนั้นใน REPL จึงมีโค้ดเสริมอย่าง macro expander, runtime module system, interpreter ฯลฯ รวมอยู่ด้วย
      ส่วนตัวอย่างจริงอย่าง todo.wasm มีขนาดประมาณ 566K (บีบอัดแล้ว 143K) และยังรวมอัลกอริทึม diff ของ virtual DOMไว้ด้วย
      คาดว่าถ้าปรับแต่งเพิ่ม เช่น ลดจำนวนตัวแปรภายใน หรือรับเอา ข้อเสนอ stack switching มาใช้ ก็จะลดขนาดลงได้อีก
      ประเด็นที่เกี่ยวข้องสรุปไว้ ที่นี่

  • woot

  • นี่แหละคือสิ่งที่ JavaScript เคยตั้งใจจะเป็นตั้งแต่แรก
    ถ้า Netscape ไม่ได้บังคับให้ใช้ไวยากรณ์แบบ C/Java มันอาจกลายเป็นภาษาแบบนี้ก็ได้