Hacker News 의견들

• 2010년에 이런 게 있었다면 Redis 스크립팅 언어는 Lua가 아니라 JavaScript였을 것 같음
  Lua는 언어적 이유가 아니라 구현상의 제약(작고, 빠르고, ANSI-C 기반) 때문에 선택된 것임
  Lua의 몇몇 아이디어는 좋지만, 개인적으로는 Algol 계열 문법에서 벗어난 점이 불필요하게 느껴졌음
  SmallTalk이나 FORTH처럼 새로운 추상 개념을 배우는 대가로 생기는 혼란은 가치가 있지만, Lua의 변화는 그만큼의 이유가 없다고 생각함

  • Lua의 문법이 마음에 드는 건 아니지만, 개발자들이 선택한 이유는 충분히 납득할 만하다고 생각함
    Lua는 tail call optimization(TCO) 을 지원하는 유일한 경량 언어로, 이 덕분에 루프 없이 재귀로만 프로그램을 짤 수 있음
    JavaScript는 이런 최적화가 없어 같은 방식으로는 불가능함
    Lua는 컴파일러 작성에도 특히 적합함. 재귀적 구조가 많기 때문임
    Redis 스크립팅에는 JS가 더 어울릴 수도 있지만, Lua를 폄하하는 건 아쉬움
  • Lua가 1993년에 처음 나왔다는 점을 고려하면, 당시로서는 꽤 전통적인 문법이었음
    브라질에서는 C보다 Pascal과 Ada가 더 널리 쓰였기 때문에 그 영향을 받은 것임
    Ruby나 Perl도 비슷한 시기에 나왔지만 훨씬 더 급진적인 문법 변화를 시도했음
  • 처음엔 13살 때 Lua를 쉽게 배웠다는 얘기를 하려다 멈췄는데, 댓글 작성자가 antirez 본인이라는 걸 깨닫고 놀랐음
  • 문법 문제를 해결하진 못하겠지만, “language skins” 개념이 흥미로움
    파서와 렉서를 분리해두면서도, {} 대신 then/end 같은 토큰을 바꿔 끼우는 시도는 거의 없었음
    관련 논의: HN 스레드, Reddit 토론
  • 혹시 Redis 스크립팅 언어로 Tcl은 고려되지 않았는지 궁금함. 원조 임베디드 언어이기 때문임

• 이 엔진은 예전에 JSC 작업할 때 내가 원하던 방식으로 JS를 제한함
  웹에서는 호환성 때문에 이런 제약이 불가능하지만, 임베디드 환경에서는 오히려 이런 제약이 기쁨을 주는 설계가 될 수 있음

  • 이미 이런 제약이 없는 JS 엔진을 가지고 있음
  • JSC에서 하던 멀티스레딩 작업은 어떻게 되었는지 궁금함. 애플을 떠난 뒤 중단된 건지, 코드가 여전히 남아 있는지 알고 싶음

• 브라우저에서 MicroQuickJS를 바로 실행해볼 수 있는 플레이그라운드를 만들었음
  MicroQuickJS WebAssembly 버전
  참고로 원본 QuickJS 버전도 있음
  QuickJS는 2.28MB, MicroQuickJS는 303KB로 훨씬 가벼움

  • 빌드에 이름 정보 등이 포함돼서 크기가 커진 듯함
    emcc -O3 옵션이나 --closure 1을 추가하면 더 줄일 수 있을 것 같음
    QuickJS는 이미 최적화돼 있고, MicroQuickJS만 개선 여지가 있음

• Jeff Atwood의 유명한 말처럼, “JavaScript로 쓸 수 있는 모든 앱은 결국 JavaScript로 쓰이게 됨”
  이제 그 말이 임베디드 시스템에도 적용되는 듯함
  Jeff Atwood 위키

  • 동의함. 관련 강연: The Birth and Death of JavaScript
  • Fabrice Bellard가 브라우저 안에서 Linux를 실행할 수 있는 JS 기반 VM도 만든 적 있음
    JSLinux 링크
  • 이건 거의 인터넷의 Rule 35 같은 느낌임

• 커밋 히스토리 없이 업로드된 게 아쉬움
  이런 수준의 개발자가 프로젝트를 얼마나 빨리 완성하는지 보고 싶었음
  어차피 QuickJS 기반이라 비교 자체가 큰 의미는 없을 듯함

  • “public repository of…”라는 표현을 보면, 실제 작업 히스토리는 비공개 저장소에 있을 가능성이 있음
  • 아마 그냥 원샷으로 완성했을 수도 있음

• 이게 yt-dlp의 YouTube JS 챌린지를 해결하는 가장 가벼운 방법이 될 수 있을지 궁금함
  yt-dlp EJS 문서 참고
  QuickJS는 이미 지원 중임

  • 가능성은 낮음. ES5 수준의 부분 구현만 지원하기 때문임
    YouTube의 JS 퍼즐은 너무 복잡해서, Python으로 만든 JS 에뮬레이터도 포기했을 정도임
  • ES5만 구현된 상태라 현실적으로 어렵다고 봄

• 임베디드 시스템은 잘 모르지만, 이런 엔진이 ESP32나 Arduino를 JavaScript로 프로그래밍할 수 있게 해줄 수 있을지 궁금함
  MicroPython처럼 말임

  • 이미 비슷한 프로젝트들이 있음
    • Espruino
    • Elk
    • DeviceScript (Microsoft Research의 중단된 프로젝트)
  • Moddable/Kinoma의 XS 엔진은 ES6 이상을 지원함
    MicroQuickJS는 ES5 일부만 구현돼 있고, 환경 바인딩도 제공하지 않음
  • 예전에 Tessel이라는 JS 프로그래밍 보드가 있었음
    JS 코드를 Lua VM 바이트코드로 변환해 실행했는데, 꽤 영리한 접근이었음
    최근 그 옛날 Node 0.8 CLI를 Rust로 다시 써봤지만, 결국 장비는 서랍으로 돌아감
  • 핵심은 malloc()이 없는 구조라는 점임. 그게 가능성을 열어줌

• 타이밍이 정말 중요함. 어젯밤에 올렸을 땐 아무 반응이 없었음

  • 아마 운의 문제일 뿐임
  • 다른 사람도 시도했지만 반응이 없었음
    미국 아침 시간대에 다시 올리거나, 주기적으로 재게시하는 전략이 있음

• Fabrice Bellard는 현존하는 가장 생산적이고 다재다능한 프로그래머 중 한 명임
  대표작: FFmpeg, QEMU, JSLinux, TCC, QuickJS
  전설적인 인물임

  • 그가 높이 평가받는 만큼, 그의 개발 방식에 관심을 가지는 사람은 적음
    최소한의 의존성과 도구로 완전한 프로그램을 만드는 접근이 인상적임
  • 이제는 그가 한 명이 아니라 숙련된 해커 집단의 코드네임일지도 모른다는 생각이 듦
    진짜 사람이라면 잠은 자야 하니까
  • 그는 LLM 추론 엔진도 직접 개발해 GPT-2 시절부터 유지 중임
    ts_server, TextSynth
  • 흥미로운 점은, 그가 만든 프로그램 대부분이 GUI 중심의 사용자 인터페이스를 다루지 않는다는 것임
    사용자가 매개변수를 설정하면 프로그램이 완결적으로 실행되는 구조를 선호하는 듯함
  • 국제 난독화 C 코드 콘테스트(IOCCC) 에서 3회 우승한 경력도 있음
    IOCCC 수상자 목록

• “10kB RAM에서도 JS를 컴파일하고 실행할 수 있다”는 점이 인상적임
  요즘처럼 RAM이 비싸지는 시기에 딱 맞는 타이밍임
  이걸 Chromium이나 Electron에 넣을 수 있을지 궁금함

  • 웹 호환성 때문에 어렵겠지만, 어차피 Chromium의 메모리 절감 효과는 크지 않을 듯함