▲

Erlang/OTP 29.0

 (erlang.org)
1P by GN⁺ 20시간전 | ★ favorite | 댓글 1개
  • SSH daemon이 기본적으로 shell과 exec 서비스를 비활성화해, 명시적으로 설정하지 않으면 인증된 사용자가 임의의 Erlang 코드를 실행할 수 없게 됨
  • SSH daemon 시작 시 SFTP subsystem도 더 이상 기본으로 활성화되지 않아 보안 기본값이 강화됨
  • -unsafe 속성이 추가되어 안전하지 않은 함수 표시가 가능해졌고, 컴파일러가 Erlang/OTP에서 항상 안전하지 않은 것으로 알려진 함수 호출에 기본 경고를 생성함
  • xref가 안전하지 않은 함수 호출과 문서가 없는 함수를 찾을 수 있으며, ignore_xref 속성 필터링도 xref 자체에서 처리하도록 바뀜
  • SSL 기본 설정에서 x25519mlkem768이 가장 선호되는 키 교환 그룹이 되었고, SSH 기본 키 교환 알고리듬도 ML-KEM-768과 X25519를 결합한 mlkem768x25519-sha256으로 변경됨
  • Erlang 시스템의 기본 코드 경로에서 현재 작업 디렉터리 . 위치가 첫 번째에서 마지막으로 이동해 로딩 순서가 바뀜
  • Windows용 32-bit Erlang/OTP 빌드가 더 이상 제공되지 않음
  • EEP-79의 native records가 구현됐으며, Erlang/OTP 29에서는 실험적 기능으로 간주됨
  • is_integer/3 guard BIF, EEP 78 기반 다중값 comprehension, compr_assign 기능을 통한 comprehension 내부 변수 바인딩이 추가됨
  • 컴파일러가 catch, 하위 표현식 밖으로 변수 내보내기, and/or, {a,B} = {X,Y} 같은 match alias 패턴에 대해 기본 경고를 추가하며 각각 비활성화 옵션을 제공함
  • 오래된 guard test는 Erlang/OTP 30에서 언어에서 제거될 예정이며, 기존의 obsolete guard 사용 경고가 계속 적용됨
  • io_ansi로 터미널에 ANSI/Virtual Terminal Sequence를 출력할 수 있고, ct_doctest로 Erlang 모듈 문서와 문서 파일의 예제를 테스트할 수 있음

함께 보면 좋은 글 β

▲
GN⁺ 20시간전  [-]
Hacker News 의견들

  • 개선이 꽤 좋아 보임. SSH 데몬을 기본 비활성화하고 SFTP도 기본 비활성화한 건 보안상 좋은 변화임
    io_ansi 모듈도 꽤 멋져 보임. 지금 Erlang은 복잡한 명령줄 애플리케이션을 만들 때 딱 좋은 이야기가 많지는 않은데, 표준 라이브러리에 들어가면 앞으로 큰 도움이 될 듯함. fwrite가 노드 간에 자연스럽게 동작하는 방식도 Erlang에서 기대하는 바로 그 장점임
    Native Records 추가도 흥미로움. 지금 Elixir에서는 상황에 따라 레코드, 튜플, 맵이 섞여 쓰이는 느낌이라 앞으로 어떻게 활용될지 궁금함. EEP에서 말하듯 기존 레코드가 완전히 폐기되지는 않겠지만, 상당한 개선으로 보임
    https://www.erlang.org/doc/apps/ssh/ssh.html
    https://www.erlang.org/docs/29/apps/stdlib/io_ansi.html
    https://github.com/erlang/eep/pull/81

    • SSH 데몬이 자동으로 활성화되거나 시작된 적은 없었던 것 같음. 두 항목의 표현은 다르지만, 의미는 SSH 데몬을 시작할 때 나열된 구성요소들이 기본으로 시작되지 않는다는 뜻으로 보임
      SSH 데몬은 이제 셸과 exec 서비스가 기본 비활성화되어 secure by default 원칙을 따름. 명시적으로 설정하지 않으면 인증된 사용자가 임의의 Erlang 코드를 실행하지 못하게 막음
      SFTP 하위 시스템도 SSH 데몬 시작 시 더 이상 기본 활성화되지 않음

  • Erlang/OTP에서 OTP가 뭔지 궁금한 사람을 위해 설명하면, 원래 통신 분야를 위해 고신뢰·장애 허용 애플리케이션을 표준화해 만들도록 해 주는 라이브러리와 원칙의 묶음임
    기본 아이디어는 “OTP Design Principles” 도입부를 짧게 읽어볼 만함
    https://www.erlang.org/doc/system/design_principles.html

    • OTP = Open Telecom Platform

  • 프로덕션 앱이 29 미만이면 이 버전이나 최신 패치 버전으로 최대한 빨리 업데이트하는 게 좋을 수 있음. 방금 프로덕션에 배포했는데 자동 보안 스캔에서 2026년 2~5월 날짜의 CRITICAL CVE 2개와 HIGH 위험 항목 여러 개가 잡힘

    • 목록이 있음?

  • 아직도 새 프로젝트에 Erlang을 쓰는 사람이 있는지 궁금함
    여기 Elixir 좋아하는 사람이 많다는 건 아는데, 순수 Erlang을 말하는 것임
    아직 Erlang을 쓴다면 Elixir보다 선호하는 이유가 뭔지 궁금함

    • 올해만 해도 있음. AtomVM 기반 새 IoT 작업, Erlang으로 작성한 애플리케이션 서버, 아직 작업 중인 TUI 프레임워크가 있음
      Elixir가 내게 Erlang 대비 실질적인 장점을 주지는 않음. 분명 장점이 있을 수는 있겠지만 Erlang이 내 사고방식에 더 잘 맞음. 배우거나 도움받는 걸 사회적 모임처럼 해보고 싶기도 한데, 나한테 맞는 자리를 잘 못 찾겠음

  • 내부 구조를 누가 설명해줄 수 있음?

  • 레코드가 생태계에서 어떻게 자리 잡을지 궁금함

    • “레코드는 수십 년 전부터 있었는데?”라고 하려다가 변경 로그를 읽어봤음
      흥미로움. Elixir가 언젠가 맵을 native records로 컴파일하는 세계가 있을지 궁금함

  • WhatsApp이 아직 Erlang 기반인지 아는 사람 있음?

    • 맞음
      2010년대 초부터 Erlang을 써왔는데, 그 무렵 기술 업계가 WhatsApp이 엔지니어 30명 정도로 활성 사용자 4억 명 이상을 지원한다는 걸 알게 됐음
      당시 그쪽 엔지니어 한 명에게 연락했고, 미국에 살던 시절 이메일로 몇 가지 질문에 친절히 답을 받았음. 결국 커피도 마셨고 지금까지도 연락하고 지냄
      Erlang은 지금도 WhatsApp의 중요한 일부라고 말할 수 있음
    • Code BEAM Europe 2025에서 발표한 걸 보면 아직 그럴 가능성이 꽤 높음: https://www.youtube.com/watch?v=tC435RGwRCI
    • 직접 아는 건 아니지만 2019년에 떠났고, WhatsApp의 공개 Erlang 관련 저장소들은 아직 활발함. 아는 한 Erlang이 Meta 전체로 퍼진 것도 아니라서, WhatsApp이 Erlang에서 벗어났다면 이후에 Erlang 작업을 계속할 이유가 별로 없음
    • 맞음. 예전 내 직원이 지금 그쪽에서 일함
    • 맞음. Erlang을 쓰고 있고 Rust도 점점 늘어나는 중임

  • -unsafe 속성 지원 추가라니, Rust로 다시 쓰기 딱 좋은 타이밍이네 /s

  • Erlang은 대체 누가 쓰는지 모르겠음. Rails를 쓰다가 Phoenix를 써봤는데, 뭔가 해내기가 훨씬 어려웠음
    Phoenix에 대한 열광을 이해하지 못하겠음
    1인 개발자에게는 Rails가 아마 가장 생산적인 웹앱 시스템임. LLM도 Ruby on Rails 코드를 아주 잘 작성함. Python 학습 말뭉치가 엄청 큰데도, 내 경험상 Django보다 훨씬 잘 씀
    실험적인 앱은 Rails로 쓰고, 안정화되면 Go로 다시 작성함. 앱 범위가 불분명할 때 Go로 바로 쓰면 토큰을 훨씬 많이 쓰지만 Rails에는 매우 효율적임
    요즘은 React나 Angular도 더 이상 필요 없고, Rails에서는 Hotwire를 쓰고 Go에서는 HTMX를 씀
    Erlang 포럼 자체도 Rails로 작성된 Discourse를 사용함

    • 2016년부터 Elixir 앱을 풀타임으로 작성해왔음. 클라이언트들은 크래시를 보지 않는 것에 매우 만족함. 실제로 지난 10년간 프로덕션에 배포한 모든 애플리케이션은 100% 가동 시간을 기록했음. 내가 통제할 수 없는 하드웨어, 운영체제, 네트워크 장애는 제외함
      시야를 좀 넓혀보는 게 좋겠음
    • Rails가 Phoenix보다 빠른 건, 개발 속도 기준으로 대략 첫날 정도뿐이라고 봄. 그 뒤에는 암묵적 로직, method_missing 같은 것에 부딪히고, 동작 방식을 파악하느라 시간이 더 듦
      Elixir/Phoenix는 그 점에서 더 명시적이라 장기 유지보수, 그러니까 첫 주를 넘긴 뒤부터는 훨씬 편함. 숨은 상태가 없고, ModuleName.method(params)가 어디서 오는지 찾아 헤맬 필요도 없고, 해당 메서드를 실행하려고 뭔가를 설정할 필요도 없이 올바른 인자를 넘기면 됨. 단점은 바로 쓸 수 있는 패키지 라이브러리가 더 작다는 정도임
    • Ruby Discord가 뭘 쓰는지 한번 맞혀볼래?
    • Phoenix가 주로 흥미로운 이유는 OTP와 채널, 그리고 LiveView 때문임. 다만 LiveView는 2026년에 내가 고를 선택지는 아닐 것 같고, 그런 기능들이 필요 없다면 매력이 덜할 수 있음
      Ecto도 나쁘지 않음
      Claude Code는 Elixir 코드를 아주 잘 작성함
      놀랍게도 LLM이 있든 없든, 원래 아는 기술을 쓸 때 더 생산적임
    • “앱 범위가 불분명할 때 Go로 바로 쓰면 토큰을 훨씬 많이 쓰지만 Rails에는 매우 효율적”이라고 쓰는 절대적인 아이러니가 있음. 이렇게 길게 늘어놓고서 정작 코드는 본인이 쓰는 게 아니라고 드러낸 셈임
답변달기