▲

웹어셈블리에서 실행되는 Scheme — Hoot 프로젝트

 (spritely.institute)
1P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • Scheme 코드를 WebAssembly(GC 지원 브라우저) 에서 실행할 수 있도록 설계된 프로젝트로, Scheme→Wasm 컴파일러와 완전한 Wasm 툴체인을 포함
  • GNU Guile 기반으로 구축되어 있으며, 추가 의존성이 없고 자급형(toolchain self-contained) 구조를 가짐
  • Guile REPL 환경에서 Wasm 인터프리터를 통해 Hoot 바이너리 테스트가 가능
  • 최신 버전은 v0.7.0으로, 릴리스 파일·서명·문서·공식 발표 링크가 제공됨
  • Scheme 언어를 웹 환경으로 확장하려는 시도로, 브라우저 기반 Lisp 생태계 확장 가능성을 보여줌

Hoot 개요

  • Hoot은 Spritely Institute가 개발한 프로젝트로, Scheme 코드를 WebAssembly(Wasm) 상에서 실행 가능하게 함
    • GC(Garbage Collection) 기능을 지원하는 웹 브라우저에서 동작
    • Scheme 코드를 Wasm으로 변환하는 컴파일러와, Wasm 관련 개발을 위한 완전한 툴체인을 포함
  • Guile 위에 구축되어 있으며, 추가적인 외부 의존성이 없음
    • 툴체인은 자체적으로 완결되어 있고, Wasm 인터프리터를 내장해 Guile REPL에서 Hoot 바이너리를 직접 테스트 가능

배포 및 개발

  • 최신 릴리스는 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 인터뷰 영상을 통해 개발자 관점의 추가 정보 확인 가능
▲
GN⁺ 6시간전  [-]
Hacker News 의견들

  • 최근 Guile의 개발이 활발해지는 게 흥미로움
    다만 예전 Racket 커뮤니티의 사람들이 많이 옮겨오는 것 같아 아쉬움이 있음
    커뮤니티가 분리되는 건 슬픈 일이고, Guile은 여전히 Racket보다 성능이나 라이브러리 다양성 면에서 뒤처지는 느낌임

    • 내 경험상은 오히려 반대였음. Guile이 Racket보다 시작 속도가 빠르고, 내가 하는 작업이 대부분 I/O 중심이라 Guile이 더 나았음
      벤치마크는 다르게 나오지만, 직접 확인해볼 필요가 있을 듯함
    • Guile은 현재 바이트코드 VM + JIT 구조라 Chez/Racket보다는 느리지만 꽤 빠름
      60fps로 게임을 돌릴 수 있을 정도이고, GC도 드물게 일어남
      예전보다 라이브러리 생태계도 많이 좋아졌음
    • 예전에 Racket 커뮤니티에서 ‘Missing Stair’ 문제가 있었다는 블로그 글을 본 기억이 있음
      (Missing Stair 위키)
      그 사건 이후 커뮤니티가 분열된 건 어쩔 수 없는 결과로 보임
    • Guile이 주목받는 건 반갑지만 Racket을 과소평가하긴 이름
      • Guile의 WASM 작업은 유망하고, Racket 쪽에서도 Jens Axel Soegaard가 관련 컴파일러를 개발 중임
      • Racket의 Chez 기반 재호스팅은 좋은 선택으로 보이고, 내부 구조도 Guile보다 다루기 쉬워졌을 것 같음
      • Racket은 여전히 메타프로그래밍과 모듈 시스템이 강점임
        예를 들어 Overeasy로 테스트를, McFly로 문서를 인라인으로 작성할 수 있음
      • Scheme 계열은 여전히 “취업 키워드”를 신경 쓰지 않아도 되는 사람들의 언어로 남아 있음
        최근 AI 코드 생성과 VC 투자 붕괴 이후 업계 분위기가 더 어려워진 것도 영향이 있음
    • Guile의 다른 구현체인 Hoot(예: V8 위에서 동작)이 벤치마크된 적이 있는지 궁금함

  • 프로젝트 자체는 멋지지만, Guile이 아닌 다른 언어를 썼으면 좋겠다는 생각이 듦

    • 그래도 Guile은 Guix의 언어이기 때문에 생태계가 풍부함
      Guix를 통해 재현 가능한 빌드를 쉽게 만들 수 있음
      다만 디버거, 매크로 확장기, R6RS 표준 라이브러리 관련 문제는 여전히 남아 있음
      Racket의 멀티코어 지원은 예전엔 무거웠지만, Guile의 fibers/futures와 비교해 지금은 개선된 듯함
    • Guile이 아닌 다른 Scheme 구현을 쓰자는 말이라면, 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에는 매크로 확장기, 런타임 모듈 시스템, 인터프리터 등 추가 코드가 포함되어 있음
      실제 예제인 todo.wasm은 566K(압축 시 143K) 정도이며, 가상 DOM diff 알고리즘도 포함됨
      추가 최적화로 지역 변수 수를 줄이거나, stack switching 제안을 채택하면 크기를 더 줄일 수 있을 것으로 기대함
      관련 이슈는 여기에 정리되어 있음

  • woot (짧은 감탄 표현)

  • 이게 바로 JavaScript가 원래 지향하던 모습이었음
    Netscape가 C/Java 스타일 문법을 강요하지 않았다면 이런 언어가 되었을지도 모름

답변달기