Hacker News 의견

• git 저장소는 여기에서 확인 가능함

• BEAM을 제대로 이해하고 싶어서 계속 파헤치게 된다는 저자의 동기가 인상적임. 이런 열정이 멋진 결과물을 만들어낸다고 생각함. 그래서 바로 구매 결정. 내 경험을 말하자면 출판사로부터 여러 번 책 집필 제안을 받았지만, 서로 원하는 방향이 달라서 성사된 적이 없음. 예를 들면, 나는 14살 대상 Java 입문서는 쓰기 싫었고, 출판사는 내가 깊게 파는 주제(예: classloader)에는 관심이 없었음. 개인적 열정과 독자의 니즈가 만나는 교집합을 어떻게 찾는지 남들은 어떻게 하는지 궁금함

  • 책을 세 권 써본 경험으로 볼 때, 자가 출판하거나 출판사가 원하는 책을 쓰거나 둘 중 하나임. 출판사마다 추구하는 책의 색깔이 다르고, 초급자용 실용서에 집중하는 곳이 많아서 대중적이지 않은 주제를 쓰고 싶으면 자가 출판을 준비하는 것이 현실임. 다행히 요즘은 자가 출판이 쉬워져서 온라인으로 판매도 가능함. 즉, 아주 틈새 시장을 겨냥한 주제라면 출판사를 기대하지 말고 스스로 출판과 홍보를 맡아야 한다는 점이 현실임
  • 본인이 흥미로운 이야기를 한다면 결국 독자들은 그걸 이해하기 위한 방법을 찾게 됨. 경력 초기에 Don Box의 “Essential .Net”을 읽었는데, 그도 특정 독자층을 노린 느낌이 아니었음. 그냥 CLR 내부를 깊이 파헤친 책이었고, 처음에 완전히 이해하려면 여러 번 읽어야 했음
  • 출판사에 꼭 의존해야 하는지, 아니면 스스로 독립적으로 책을 써도 되는 건지에 대해 고민함. 출판사의 이름이나 부가적인 이득 때문인지 궁금함
  • 가르친다는 행위가 가장 좋은 학습법이라는 점에 동의함. 고등학교 때 수학 튜터하며 배웠고, 책을 쓰는 경험도 비슷함. 단순한 이해를 넘어서 근본적인 내용을 내 것으로 만드는 최고의 방법임
  • 약간 자랑 같지만, 나도 등반을 위한 근력 트레이닝 책을 이렇게 파고들다 쓰게 됨. 원래는 자가 출판하려 했지만, 결국 출판사를 찾아 약간 더 읽기 쉽게 수정했음. 출판사에 직접 접근해 보는 것도 방법임

• BEAM과 Erlang/OTP를 다뤄 본 경험이 지난 1년 중 가장 좋았던 개발 경험 중 하나임. Joe Armstrong의 “Programming Erlang: Software for a Concurrent World” 책을 사용했고, 초보자에게 강력 추천하고 싶음. “Designing for Scalability with Erlang/OTP”도 평이 좋지만 아직 시작은 못했음. 하지만 깊이 면에서는 이번 책이 압도적임. BEAM은 정말 고대 문명이 남긴 외계 기술 같음. 좋은 타이밍에 저 책이 나와서 바로 구매. 두 번이나 출간이 취소된 뒤에도 책을 완성해 준 Erik Stenman 박사에게 감탄함

  • BEAM/Erlang/OTP로 어떤 소프트웨어를 개발했는지 궁금함

• Elixir와 BEAM은 네트워크 기반이나 파이프라인이 많은 시스템 구축에 최애 선택임. 몇 년간 프로덕션에서 매일 사용했고, 최근 프로젝트에서는 선택이 쉽지 않지만 꾸준히 동향을 챙김. 이 책 출간이 고마움. 몇 년 전 프로덕션 Elixir에서 디버깅하면서 꼭 원했던 책임. 기존 자료는 너무 어렵거나 반대로 너무 단순해서 아쉬웠음

• BEAM(Erlang virtual machine) 정보는 위키백과 링크에서 확인 가능함

  • 책 제목에 이미 잘 설명되어 있음

• BEAM이 오픈소스 분야에서 가장 과소평가된 기술 중 하나라고 생각함. 예시로 whatsapp이 있음. Elixir와 Erlang이 높은 동시성 프로젝트에 더 인기가 없는 이유가 미스터리임

  • 내 직장은 Erlang 전문 회사임. Erlang의 진가는 수백만 DAU처럼 대규모 트래픽에 있음. Elixir로 수천 DAU 웹사이트를 돌릴 순 있지만, Erlang과 BEAM의 본질은 그 스케일에 있음. 이런 규모가 필요한 회사는 많지 않고, 더 큰 문제는 Erlang 생태계 자체가 마치 별도의 OS처럼 동작해서 환경 설정과 구성요소가 상당히 복잡함. 컨테이너나 k8s 같은 다른 인프라 기술도 필요 없고, 오히려 Erlang의 고유 방식 때문에 익숙하지 않게 느껴짐. 딱 들어맞는 상황에서 Erlang을 경험한다면, 일종의 마법 같다고 생각함. 내 커리어 하이라이트임
  • 결국 마케팅의 영향이라고 생각함. Java, C#, Go는 막강한 기업 후원이 뒷받침하지만 Erlang은 오히려 기업이 발목을 잡거나 기술 문서 외에는 별 신경을 안 씀. Elixir는 처음으로 다른 언어식 마케팅(루비 모델)을 따라갔으나, 진입 시점과 상황이 다름. 개발자들은 BEAM의 우수성을 납득하겠지만, 그 외의 의사결정권자들에게 어필이 잘 안 되는 것 같음
  • 투자 차이가 크다고 생각함. Rust, Go, Python 등은 기업 지원으로 정적 분석, 타입 체크, 개발자 경험 등에서 많은 투자가 이뤄졌지만, Erlang 쪽은 이러한 사랑을 충분히 받지 못했고, 대형 사용자들도 점차 BEAM 바깥에서 직접 솔루션을 만들거나 전향함
  • 우리는 최근 Squarespace 웹사이트를 Phoenix 애플리케이션으로 바꿨는데, 정말 즐거운 경험이었음
  • 동시에 가장 덜 비밀스러운 ‘비밀 소스’임. 최근 BBC도 Elixir로 전환했으니 점점 인기도 올라가는 중이라고 느낌

• “Erlang Runtime System(ERS)”은 일반적인 Erlang 런타임을, “Erlang RunTime System(ERTS)”는 Ericsson 구현에 국한된 표현이라는 설명이 좋음

  • 저 정의가 바보 같지 않다고 생각함

• 바로 책을 구매함. 온라인으로 무료로 볼 수 있지만 저자를 조금이나마 지원하고 싶어 구매함

• Klarna 같은 대규모 시스템을 하지 않아서 체감이 어렵지만 15ms 딜레이가 포스트모템 이슈가 된다는 게 신기함

  • BEAM에서는 마이크로초(μs) 단위 응답이 일반적이어서, 밀리초(ms)로 튀면 바로 경보가 울릴 수 있음
  • BEAM 시스템에서는 이런 상황이 충분히 발생함. 공유 상태 보호를 위해 gen_server를 만들면, 이건 거대한 뮤텍스 같은 개념임. gen_server가 요청을 처리하는데 20us 걸린다고 하면, 15ms 딜레이면 메시지 큐에 750개의 메시지가 쌓임. 여기에 메시지 큐를 비효율적인 패턴으로 쓰면 성능이 급감함. BEAM은 특정 패턴만 메시지 큐 최적화를 해 주지만 나머지 패턴의 경우 큐 길이에 따라 처리 시간이 증가함. 라이브러리 내부에서 안전하지 않은 receive가 쓰이면 예상치 못한 성능 저하 발생. 최근에 BEAM이 메시지 큐 문제를 보완하는 'alias' 기능을 추가했지만 많은 라이브러리가 아직 사용하지 않음. alias는 메시지 손실 방지가 목적이고, 타임아웃 메시지로 큐가 오염되는 걸 막아줌. 보통 장수 프로세스는 큐를 루프로 돌면서 처리함
  • 언급된 사건의 포스트모템 링크 아시는 분 있으면 궁금함. 온라인에서 못 찾았음

• BEAM과 유사한 VM이 있는지 궁금함. 혹시 BEAM이 워낙 뛰어나서 경쟁 제품이 없는 건지, 아니면 그만큼 만들기 어렵기 때문인지 알고 싶음

  • 현대 Kubernetes 인프라가 제공하는 기능이 BEAM과 비슷하다고 봄. 요즘은 이런 인프라로 대규모 셀프힐링 시스템을 구현하며, 언어 제약도 없음. Erlang/Elixir 말고도 다양한 생태계와 인력, 관심사가 존재함
  • AtomVM이라는 IoT 등 제약이 큰 장치용 별도 구현도 있음. BEAM이나 OTP를 다른 생태계에서 구현하려던 시도는 많았지만, 대부분 VM 레벨은 아님
  • BEAM이 90년대 후반, 2000년대 초에 나온 시기에는 꽤 독특했음. 지금은 구현 방식만 다를 뿐 같은 문제를 다양한 언어와 도구로 잘 풀 수 있음. Erlang 커뮤니티 특유의 “BEAM 방식 만이 정답”이라는 태도도 있지만, 2025년에는 정말 다양한 옵션이 존재함. BEAM 호환 구현도 있지만, 대부분 니치한 영역임. 기존 BEAM 인프라에 합류해야 하는 게 아니라면, 녹색필드 프로젝트에는 요즘 생태계의 현대적인 솔루션이 더 적합하다고 생각함. ergo 같은 소규모 프로젝트도 있음
  • Dis VM이 아마 가장 비슷하고, 그다음이 Smalltalk VM임. 사실 BEAM 자체보다 OTP가 얹혀 BEAM이 진가를 발휘함
  • 실사용에서 가장 비슷한 건 아마 Go일 것임. BEAM은 “Erlang류 언어”에 맞춘 생태계라 Elixir나 Gleam도 핵심 동작이 Erlang과 유사함. Go가 goroutine 등 병행성에서 Erlang식 primitive를 제공하지만, OTP처럼 애플리케이션 구조에 대한 뚜렷한 관점은 없음