나의 가장 좋아하는 Erlang 프로그램 (2013)

 (joearms.github.io)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 제공된 노트 범위만으로는 제목의 Erlang 프로그램이 무엇인지나 왜 중요한지 확인할 수 없음
  • 확인 가능한 텍스트는 주로 Shell 스크립트 조각과 짧은 정정 문장에 그침
  • 스크립트는 현재 디렉터리의 *.png.png.meta 파일을 순회하며, 파일명에서 첫 번째 점 이전 부분을 추출함
  • 실제로 실행되는 명령은 git mv $i $j.png.meta이고, $j.png.png를 $j.png로 바꾸는 명령은 출력만 됨
  • 원문 청크 5-104가 생략되어 있어, 제목과 관련된 핵심 주장이나 Erlang 코드 설명은 확인할 수 없음

확인 가능한 내용

  • 제공된 범위만으로는 “가장 좋아하는 Erlang 프로그램”의 정체, 선호 이유, 코드 구조를 판단하기 어려움
  • 확인 가능한 코드 조각은 #!/bin/sh로 시작하는 파일명 변경용 Shell 스크립트임
    • *.png.png.meta 파일을 대상으로 반복함
    • j="${i%%.*}"로 파일명에서 첫 번째 점 이전 부분을 추출함
    • git mv $i $j.png.meta는 실제 실행됨
    • git mv $j.png.png $j.png는 echo로 출력만 됨
  • “Actually you don't need the really do this. It should have been water the plants.”라는 문장이 있으며, 앞선 지시나 예시가 실제로는 필요 없었고 “water the plants”였어야 한다는 정정으로 읽힘
  • 마지막에는 Joe Armstrong과 Jeremy Ruston이 함께 언급됨

판단을 제한하는 맥락

  • 여러 청크가 TiddlyWiki 상태/사이드바 메타데이터, JPEG/PNG로 보이는 Base64 데이터, 빈 내용으로 구성되어 있어 본문 사실을 추출하기 어려움
  • 제공된 노트에는 Erlang 프로그램의 동작, 코드, 설계 이유, 예시, 숫자, 워크플로, 주장 같은 핵심 정보가 포함되지 않음
  • Shell 스크립트 조각도 주변 설명 없이 일부만 제공되어, 어떤 작업의 일부인지 확정할 수 없음

생략된 범위

  • 입력에 원문 청크 5-104가 길이/비용 제한으로 생략되었다고 명시되어 있음
  • 이 요약은 제공된 노트 범위만 반영하며, 원문 전체의 세부 내용이나 결론을 포괄하지 않음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 서버 클로저 F가 자기 메시지 외에도 {become, F} 메시지를 받을 수 있다면, 서버를 계속 새 동작으로 바꿔 갈 수 있음
    전혀 다른 얘기지만, Erlang 컨퍼런스에서 Joe와 얘기했던 기억이 남아 있음. 그는 늘 기술에 들떠 있었고 누구와도 기꺼이 대화했음. Windows가 해마다 더 나빠지고 덜 쓸만해지는 걸 안타까워했고, 언젠가는 파일을 보려면 광고를 한동안 봐야 잠금이 풀릴 거라고 했는데 거의 맞아감. Windows 11에는 이미 광고가 있고, 지우려면 일부러 설정을 찾아야 하니 Windows 13쯤엔 정말 그렇게 될 것 같음

    • 집에서는 Linux를 쓰고 일에서는 Windows를 쓰는데, 광고보다 더 놀란 건 Windows에서 예전 Linux에서나 보던 이상한 문제들이 훨씬 자주 보인다는 점임
      한쪽 이어폰 소리만 훨씬 크다거나, Microsoft 앱이 이상하게 죽는다거나, Windows 문서 페이지가 어떤 브라우저에서도 열리지 않아 아카이브 사이트를 써야 한다거나, 잘 잡히던 외부 모니터를 갑자기 못 잡거나 화면이 깜빡이는 식임. Office는 기본적으로 로컬이 아니라 클라우드에 저장하도록 유도하는데, 파일은 로컬 우선이고 클라우드는 백업이면 좋겠다는 쪽임. WSL은 꽤 엉성하지만, 그나마 Windows를 쓸 수 있게 해 주는 거의 유일한 이유임
      Joe가 훌륭한 사람이었다는 얘기를 늘 들었고 납득이 감. 처음 코딩을 독학할 때 그의 Erlang 책을 봤는데, 장난기와 겸손함, 상상력이 큰 영향을 줬음. Erlang을 거의 쓰게 되진 않았지만 그의 글은 코드에 대한 사고방식을 바꿔 줬고, 수학·소프트웨어 공학·컴퓨터 과학 문화가 장난기와 겸손함을 더 받아들였으면 좋겠음
    • 첫 문단의 내용은 사실 액터 모델의 기능임. BEAM에서도 가능하다는 건 전에는 몰랐음
    • Windows 11의 침입형 광고가 새로 생긴 건 아님. 이미 Windows 10에도 들어가 있음

  • BEAM이 JVM이나 Node 같은 다른 가상 머신과 왜 다른지 설명하는 짧은 35분 개요 영상: https://www.youtube.com/watch?v=pO4_Wlq8JeI

    • 비슷한 발표인 The Soul of Erlang and Elixir를 봤는데 정말 좋았고, 볼 때마다 다시 흥분됨

  • Joe가 그립다. 컴퓨팅을 더 낫게 만들려는 전염성 있는 열정이 젊은 시절의 나와 지금의 기술 접근 방식에 깊게 남아 있음

  • universal_server() -> receive {become, F} -> F() end.
    솔직히 이 universal_server의 힘을 완전히 이해하지 못하겠음. 누가 설명해 주면 좋겠음

    • Go에 익숙하다면, 누군가 익명 함수를 보내 실행시키기를 기다리는 고루틴과 비슷함
      Erlang에서는 많은 프로세스를 띄워 문제를 풀고, 대부분의 프로세스는 메시지를 기다림. 중요한 차이는 Erlang 프로세스가 원격 머신에서도 매끄럽게 실행될 수 있다는 점임. 이 프로세스는 become이라는 원자와 함수가 들어 있는 튜플 메시지를 받고, 다른 프로세스가 언제든 그 메시지를 보내면 그 함수로 “변신”함
      즉 대기 루프의 로직을 원하는 프로토콜 로직으로 갈아끼울 수 있음. 예시로는 여러 머신에 이 루프를 띄워 두고 가십 프로토콜을 구현한 함수를 보냈지만, 똑같이 BitTorrent 클라이언트가 되게 하는 메시지도 보낼 수 있음. Joe는 천재이면서 매우 친절한 사람이었고, Erlang은 지금까지 본 가장 아름다운 기술적 창작물 중 하나임. 동시성을 완전히 새롭게 보게 해 줌
    • 조금 더 풀면, receive 키워드는 들어오는 메시지에 대한 switch문 같지만 실제로는 패턴 매칭임
      예를 들어 {From, N}을 받아 From ! factorial(N)으로 결과를 돌려주는 팩토리얼 서버를 만들 수 있음. !는 결과를 반환 프로세스로 보내는 연산자임
      테스트 코드는 universal_server를 띄우고, Pid ! {become, fun factorial_server/0}로 팩토리얼 서버가 되게 한 뒤, {self(), 50}을 보내 50의 팩토리얼을 돌려받음. Erlang의 큰 장점은 분산 병렬성과 핫 코드 업데이트이고, 여기서는 universal_server의 수신 루프를 factorial_server의 수신 루프로 덮어쓰는 형태로 드러남. 다만 실제 핫 코드 업데이트는 정확히 이런 방식으로 동작하진 않는다고 봄
    • 보통은 서버가 무엇에 쓰일지 미리 알고 코드를 작성해야 함
      하지만 Erlang에서는 분산된 Erlang 서버 네트워크를 만들고, 서버를 클라이언트가 원하는 일을 할 수 있는 범용 계산 자원으로 둘 수 있음. 코드는 클라이언트에서 오며, 모든 머신에 바이너리를 설치해 달라고 시스템 관리자에게 부탁할 필요 없이 함수를 전달하면 원격 머신이 호출함
    • 핵심은 원하는 어떤 종류의 서버로도 변신할 수 있다는 점임
      서버를 실행할 실제 함수는 클라이언트가 전달하고, Erlang 프로세스는 그 함수를 바탕으로 해당 서버가 됨. Erlang의 핫 리로딩 능력까지 고려하면 이 단순한 구조가 더 강력해짐. Erlang 프로세스는 일을 기다리는 계산 자원이고, 그 일이 완전한 서버를 실행하는 것이라고 보면 꽤 멋짐
    • Erlang의 구조는 특이해서, 가상 머신과 언어 모두 작은 프로세스들이 동시에 동작하고 각 프로세스가 들어오는 메시지를 해석하기 위해 무한 루프에서 기다린다는 아이디어 위에 세워져 있음
      그래서 프로세스는 보내는 코드에 따라 무엇이든 될 수 있음. 전자레인지를 제어하다가, 양자 계산을 하고, 다음 날 축구 경기 승자를 예측해야 한다면 각 작업에 필요한 코드를 보내면 그대로 수행함

  • BEAM이 왜 특별한지, Erlang/Elixir 등의 동시성이 Go나 Java의 동시성과 왜 다른지 설명하는 데 많은 시간을 씀
    이제부터는 Joe가 가장 좋아한 Erlang 프로그램과 이 HN 스레드를 링크하면 될 것 같음

  • 이 블로그 글은 최근의 훌륭한 발표에서도 다뤄졌음: https://youtu.be/pQ0CvjAJXz4

    • 고가용성·장애 허용·분산 Erlang 시스템 아키텍처의 각 단계를 아주 잘 다루고 설명하는 발표임
    • 환자마다 하나의 Erlang 프로세스로 표현되는 그 시스템인지 궁금함

  • Erlang은 언어에 대한 고수준 이해만 있고 직접 프로그래밍해 보진 않았는데, 이 코드가 왜 필요한지 궁금함
    universal_server() -> receive {become, F} -> F() end.
    그냥 원격 머신에서 F()를 직접 띄우면 되지 않나 싶음. 원격 가상 머신에 F 코드가 이미 있어야 해서, 이 예시는 F의 코드를 직렬화해 전달한다는 의미일 수도 있겠음. 공통 보일러플레이트를 처리한다면 유용성을 이해하겠지만, 지금은 become F 메시지를 기다렸다가 F()를 실행하는 것처럼 보임

    • 이 코드는 멋지지만 매우 관용적이거나 실제 운영 코드에서 자주 볼 방식은 아닐 수 있음. 그래도 Joe는 탐구와 실험을 좋아했음
      여기서 F는 클로저라서 코드뿐 아니라 캡처한 변수와 생성 당시 환경도 포함할 수 있음. F()를 호출하면 그 코드가 실행되고, F가 만들어졌을 때의 주변 환경에 접근할 수 있음
      Erlang에서는 클로저를 네트워크 너머 다른 Erlang 노드로 보낼 수 있음. 다만 클로저가 참조하는 모듈 코드는 모든 노드에 있어야 함. 운영 코드라면 말한 대로 F 모듈을 직접 호출하고 인자를 명시적으로 넘길 가능성이 크며, 이건 가능성을 보여 주는 멋진 시연에 가까움
    • Erlang의 함수형 설계 덕분에 F()는 이전의 어떤 문맥만큼이나 좋은 최상위 문맥이 될 수 있어서 멋짐
      기존 요청은 예전 로직으로 자연스럽게 처리하면서 새 요청은 새 로직으로 시작하게 할 수 있고, 결국 예전 로직은 가비지 컬렉션될 수 있음
    • 원격 가상 머신에 F 코드가 이미 있어야 하는 건 맞지만, 코드를 원격 가상 머신으로 보낼 수도 있음
      예를 들어 Elixir에서는 Code.compile_string으로 모듈 이름과 BEAM 바이트코드 바이너리를 얻을 수 있음. 그 바이트코드를 다른 가상 머신에 보내고 :rpc.call('node@remote_host', :code, :load_binary, [the_module_name, "filename_doesnt_really_matter", binary_code])로 원격 가상 머신에 로드한 다음, spawn('node@remote_host', my_module, my_function, [args])로 띄울 수 있음
    • 인용된 프로그램은 원격 머신에서 실행되도록 의도됐고, 원격 머신이 새로 실행해야 할 프로그램을 역직렬화함
      여기서 F는 직렬화되어 프로세스 간 메시지로 보내진 새 프로그램을 나타내는 변수이며, 이 경우 네트워크를 통해서도 전달됨

  • Joe가 Erlang으로 기본 서버를 작성하는 방법을 설명한 강의도 있음: https://gioorgi.com/2015/erlang-lesson1/
    직접 받아 적고 조금 더 설명했는데, Erlang/Elixir 같은 비동기 언어가 다른 언어에 비해 갖는 힘을 보여 줌. 아쉽게도 요즘은 많이 쓰이지 않음

  • 최근 Julia에 빠져 있는데, 분산 모델에서 Erlang의 아이디어를 꽤 빌린 것처럼 보임
    여러 노드에 걸쳐 마법처럼 동작하는 이런 즉석 서버를 Julia에서도 꽤 쉽게 재현할 수 있음. 확실하진 않지만 Julia의 Distributed 모듈이 Erlang에서 조금이라도 영감을 받지 않았을 리는 없어 보임
    Erlang을 정말 좋아하고 더 쓸 기회가 있었으면 좋겠지만, 그 개념들이 다른 플랫폼으로 스며드는 걸 보는 것도 좋음

    • Julia 커뮤니티에서 Erlang의 오류 보고 철학에서 나온 let it crash 같은 교훈을 설득할 때 서로 같은 편일 것 같음
답변달기