Elixir 1.17 출시: 패턴의 집합 이론적 타입, 기간, OTP 27

 (elixir-lang.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 점진적 집합 이론 타입이 패턴에서 타입을 추론해 컴파일 시점 경고를 내며, 기존 소프트웨어 변경 없이 코드베이스의 결함과 버그를 찾는 기능 추가
  • 새 타입 경고는 현재 atom과 map/struct에 초점을 두며, 존재하지 않는 키 패턴 매칭·필드 접근, 비모듈 함수 호출, 잘못된 익명 함수 호출, 구조체 간 구조적 비교, 겹치지 않는 타입 비교, 잘못된 binary 패턴, 정의되지 않은 예외 rescue 등을 감지함
  • 타입체커는 현재 같은 함수 안의 패턴에서만 타입을 추론하며, guard와 함수 경계 간 분석은 향후 릴리스에 추가될 예정임
  • Erlang/OTP 27 지원이 추가되고 Erlang/OTP 24 지원이 중단됨; Windows를 포함해 Erlang/OTP 26 이상으로의 마이그레이션 권장
  • Windows용 Erlang 터미널 그래픽 인터페이스인 WERL 지원은 Elixir v1.18에서 제거 예정
  • 새 Duration 데이터 타입과 Date.shift/2가 추가되어 날짜, 시간, date time을 duration 기준으로 이동할 수 있으며, DateTime에서는 시간대 변경과 Daylight Saving Time을 처리함
  • Kernel.to_timeout/1가 추가되어 duration과 integer를 Process, GenServer 등 여러 API에서 쓰는 timeout 값으로 정규화함
  • Erlang/OTP 27의 process label 기능을 Elixir에서 Process.set_label/1로 사용할 수 있으며, Logger는 gen_statem 보고서를 포맷하고 logger 이벤트에 Erlang/OTP 27 process label을 포함함
  • Keyword.intersect/2,3, 새 Mix profiler인 mix profile.tprof, %{}가 struct도 매칭하는 함정을 줄이기 위한 guard Kernel.is_non_struct_map/1 추가
  • mix profile.tprof 추가와 함께 mix profile.cprof, mix profile.eprof는 soft-deprecation 대상이 됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 최근 몇 년 사이 Elixir 생태계가 정말 많은 용도에서 가장 단순한 해법이 되어 가고 있음
    Phoenix와 LiveView로 웹 개발은 빠르고 즐겁고, NX/Axon/Bumblebee로 인공지능, Membrane으로 오디오·비디오 스트리밍과 처리, Commanded로 CQRS와 이벤트 소싱, Nerves로 임베디드 기기 제작, 개발 중인 LiveView Native로 모바일 앱까지 가능함
    큐, 파이프라인, 일괄 처리도 기본 기능이나 GenStage, Broadway, Oban으로 용도에 맞게 처리할 수 있음
    그래도 개인적으로 핵심 기능은 Elixir의 REPL인 IEx임. 개발이나 운영 중인 코드와 직접 상호작용하고, 내부를 살피고, 디버깅할 수 있는 게 삶을 바꿀 정도임
    여기에 타입이 더해지는 건 우리가 배포하는 코드에 더 큰 확신을 주는 마지막 퍼즐 조각임

    • 여기에 더해 ExUnit은 테스트가 엄청 쉬워지고, Hex 패키지 관리자는 그냥 잘 동작하며, FLAME은 거의 한 줄의 코드로 프로세스를 다른 컴퓨터로 확장할 수 있게 해줌
      Ecto는 SQL 데이터베이스를 함수형 방식으로 다루게 해주는데, ORM을 어떻게 봐야 할지는 아직도 모르겠지만 조합 가능한 쿼리 몇 개로 SQL의 90%를 없앨 수 있었으니 성공으로 봄
      배포, 가동 시간, 세그멘테이션 오류, 패키지 시간 등으로 몇 달 고생한 뒤 웹 서버와 데이터 계층을 Elixir + Phoenix로 옮겼고, 이제 훨씬 더 잘 테스트되고 추론하기 쉬우며 확장성도 믿을 수 있고 배포도 쉬웠음
      설정보다 관례 덕분에 Phoenix로 말도 안 되게 빨리 시작할 수 있었고, FastAPI보다 훨씬 빨랐음. 몇 달 전에 했어야 했다는 생각이 듦
      지금은 Nx로 모델을 학습시키고 Bumblebee/Livebook을 만져 보며, 앱에 presence와 live 기능을 거의 공짜로 붙이고 있음
    • LiveView Native를 살짝 홍보하자면, 모바일 앱뿐 아니라 데스크톱, 워치, TV, Apple Vision Pro용도 만들 수 있음
      모두 LiveView의 개념, 성능, 개발 편의성을 그대로 사용함
    • 강력하고 유용한 정적 타입 시스템이 있는 언어에서 온 입장에서는 이게 가장 아쉬운 빈자리라서 Gleam을 궁금하게 보고 있음
      Erlang이나 Elixir 같은 곳으로는 다시 돌아가기 어려울 것 같음
    • Elixir의 REPL은 최고 수준이고, 이 언어의 진짜 킬러 기능이라는 데 동의함
      다른 언어로 코드를 쓸 때마다, 특히 돈 받고 코딩할 때마다 정말 그리움
      좋은 REPL이 있으면 프로그래밍에서 흔히 부딪히는 마찰이 크게 줄어듦. 전체 앱을 실행해 문제 있는 코드 조각을 찔러 보는 대신, 아이디어를 조금씩 쌓고 그때그때 시험할 수 있음
      Elixir 표준 라이브러리도 훌륭하고, REPL에서 문서에 접근하기가 아주 쉬워서 흐름을 유지하는 데 큰 도움이 됨. Elixir로 코딩할 때는 작은 질문을 검색하러 브라우저를 여는 일이 드문데, 보통 REPL을 떠나지 않고 답을 찾을 수 있기 때문임
      그래서 내 코드에도 좋은 문서 문자열을 쓰도록 유도됨
      더 좋은 점은 실행 중인 코드와 함께 REPL을 돌릴 수 있다는 것임. 앱을 실행해야 할 때도 그대로 실행하면서, 개발 환경에서는 라이브 데이터를 조작하고 내부 상태를 살펴볼 수 있음. 다른 스택에서는 불가능하거나 디버거가 필요한 일임
      이제 타입 관련 기능까지 들어오면 도구는 더 좋아질 것으로 기대함
      여기에 함수형 패러다임의 재미와 힘이 있고, 가변성과 상태를 다룰 견고한 방법도 있으며, LISP 문법을 감당하지 않아도 됨. 개인적으로 모든 음을 맞춰 주는 언어라 정말 좋아함
    • 다른 언어들도 이런 건 많지 않나? Ruby에는 IRB가 있음
      IEx가 IRB에는 없는 뭔가를 해주나?

  • 지난 몇 년간 Elixir와 Erlang 팀이 정말 잘해 왔고, 라이브러리와 책 저자들의 작업도 빼놓을 수 없음
    릴리스가 이렇게 기대된 적이 없었음. 한동안 Elixir와 OTP 커밋을 지켜봤는데, Elixir/Erlang이 확실히 탄력을 받은 느낌임

  • 사이드 프로젝트 백엔드로 Elixir를 쓰고 있고 프런트엔드는 Remix인데, 백엔드 작업이 아주 쾌적하고 생산적임
    LiveView의 생산성은 인정하지만, 내 경우에는 불안정한 네트워크 연결을 처리해야 해서 예상대로 LiveView 경험이 좋지 않았음
    개발자들 머릿속에서 Elixir가 LiveView와 어느 정도 분리되면 좋겠음. LiveView나 실시간 채널 없이 단순 API 백엔드로만 써도 Elixir는 정말 재미있음

    • Elixir를 정말 좋아해서 거의 모든 것에 쓰고, LiveBook은 장난감 소프트웨어를 만들기 시작하는 기본 장소가 됐음
      하지만 LiveView는 잘 못 하겠음. 이해하기가 꽤 어렵고 발밑 함정도 많음. 예를 들어 인증 검사를 라우터의 pipe_through와 LiveView의 on_mount 콜백 양쪽에서 기억해 처리해야 하는 경우가 있음. [0] 참고
      Phoenix와 LiveView를 처음 접하는 개발자에게 위 문장이 아무 의미도 없다는 사실만으로도, LiveView가 기본 방식이면 안 된다는 증거로 충분함
      필요하지 않은 곳에 아주 가파른 학습 곡선을 만들어 버림. Elixir/Phoenix 자체는 쉬움
      새로 Elixir/Phoenix를 배우는 개발자라면 먼저 MVC 스타일의 Phoenix dead views를 쓰고, 그다음 OTP 기본을 배우기 위해 “Elixir in Action”을 읽는 순서가 맞다고 봄. 이 책은 쉽고 눈이 확 뜨였으며, 거의 모든 코딩 방식을 바꿔 줬음
      그리고 그다음에야 LiveView로 가는 게 좋음
      [0]: https://hexdocs.pm/phoenix_live_view/security-model.html#liv...
    • mix phx.new를 —no-live 플래그와 함께 실행하면 LiveView 없이 Phoenix를 쓸 수 있음. 기존 프로젝트에서도 수동으로 빼낼 수 있음
    • 지금까지 달린 답변들은 핵심을 놓치고 있음
      문제는 기술 지식이나 설치 기본값의 문제가 아니라, 개발자들의 인식 문제임. 너무 많은 사람이 Elixir와 나머지 생태계를 LiveView부터 떠올리고, 그 외 생태계를 무시한 채 지나쳐 버림
      Elixir는 그보다 훨씬 많고, Phoenix조차 LiveView보다 큼
      LiveView는 물론 Phoenix도 없이도 생산적이고 비용 효율적인 Elixir 애플리케이션을 충분히 만들 수 있음. 백엔드에서 Elixir를 선택하는 일이 지금보다 더 흔해져야 하지만, 다른 선택을 하게 만드는 통념과 두려움도 이해는 됨

  • 내 스타트업을 Elixir 100% 풀스택으로 만들고 있는데, 지금까지 써본 기술 중 가장 훌륭함
    진지한 기술 친구들에게 얼마나 좋은지 계속 전도하고 있음
    이제 RabbitMQ와 그 클라이언트가 OTP 27에서 돌아가면 정말 좋겠음. 업그레이드하고 싶음

    • 어떤 일을 하고 있길래 다른 기술보다 Elixir가 딱 맞는 지점에 있다고 느끼는지 궁금함
    • RabbitMQ는 꽤 견고한데, 성능 누수 같은 문제를 겪고 있나?
      우리는 SSL 인증서 클라이언트 로그인 방식을 몇 년간 써 왔고, 안정성에 매우 만족하고 있음

  • Elixir와 Phoenix에 대해서는 좋은 말을 아무리 해도 모자람. 이제 타입까지 오면 더 좋아질 것임
    BEAM과 그 강력함에 대해 많이 듣겠지만, 경험상 스택의 그 부분을 생각해야 하는 시점까지는 정말 오래 갈 수 있음. Phoenix가 그 부분을 훌륭하게 추상화해 줘서, 노력 없이 이점을 얻음
    예를 들면 Oban이 있음. Postgres 안에서 Elixir 코드로 강력하고 유연하며 쓰기 쉬운 백그라운드 작업을 거의 공짜로 얻을 수 있음. 정말 대단함
    한번 써보길 권함

    • LiveView만 아니었다면 완전히 동의했을 것임
      LiveView와 그 주변의 마케팅 집착 때문에, 원래라면 OTP를 더 오래 몰라도 됐을 사람들이 여정의 아주 이른 시점, 어쩌면 첫 컨트롤러 라우트에서부터 OTP를 마주하게 됨
      견고한 LiveView 흐름을 작성하고 잘 테스트하는 일은, 여러 비선형 흐름과 다양한 call/cast 진입점을 가진 상태ful GenServer를 작성하는 것만큼 지적으로 복잡함
      LiveView는 다른 용어를 쓰고 async assigns 같은 작은 편의 계층이 있지만, 기계적으로는 말 그대로 GenServer임. 효과적으로 쓰려면 이 점을 잘 이해하는 게 중요하다고 봄
      Oban은 정말 좋아하고, 다른 생태계에서 깊이 그리움

  • 여담으로, elixir-desktop [1]을 써본 사람이 있나? wxWidgets + LiveView 묶음이라 Electron 앱과 꽤 비슷함
    [2]에서 Wojtek Mach는 Elixir 팀이 Livebook Desktop을 어떻게 만들었는지 설명함. 프로젝트가 어떻게 시작됐는지, macOS용 앱을 만들며 발견한 미묘한 버그, Windows에서 wxWidgets의 한계, 여러 구현 세부사항을 다룸
    Elixir 팀이 Livebook 기반으로 elixir-desktop 같은 것을 공식 출시하면 좋겠음. 즉 Livebook 저장소를 포크해 LiveView 기반 데스크톱 애플리케이션을 생성하는 공식 템플릿 프로젝트를 제공하는 식임
    지금 Livebook은 Windows와 Mac용 실행 파일로 배포됨. Electron처럼 개발자가 독립 실행 파일을 배포할 수 있게 같은 접근을 따르면 어떨까?
    LiveView Native [3]도 알고 있지만, 방향이 다르다고 봄
    [1] https://github.com/elixir-desktop/desktop-example-app
    [2] https://www.youtube.com/watch?v=Kiw6eWKcQbg
    [3] https://native.live/

  • Elixir 대중화를 가로막던 타입이 없다는 핑계가 사라질 날이 기대됨

  • 10년 동안 여기서 멋진 Elixir 이야기를 읽어 왔고, 언어도 좋아함
    하지만 Elixir 일자리는 몇 년 전에 찾기를 포기했음. 주류 언어보다 급여가 계속 낮게 보였기 때문임
    가장 쓰고 싶은 언어일 수는 있지만, 내게는 급여와 멋진 제품이 기술 스택보다 더 중요해서 실제로는 못 하게 될지도 모름. 그래도 멀리서 지켜보는 건 여전히 재미있음

    • Elixir 개발자로서는 급여가 주류 언어보다 낮다는 게 의외로 들림
      미국에서 찾고 있는 건지, 다른 지역인지 궁금함
    • 급여는 주류 스택보다 꾸준히 높은 편임. 부분적으로는 대부분의 Elixir 채용이 시니어 엔지니어를 찾기 때문임

  • 이번 릴리스의 좋은 기능은 구조체와 함께 동작하는 get_in/1 추가임. 예를 들어 get_in(struct.foo.bar)처럼 쓸 수 있음
    foo가 nil을 반환하면 bar 접근에서 예외가 나지 않음

    • 이전 Elixir 버전에서도 가능했지만 문법이 시끄러웠음
      일반 맵이 아닌 계층에는 다음처럼 Access.key가 필요했음
      get_in(struct, [Access.key(:foo), :bar])

  • 이게 내가 원하던 마지막 조각임. 이후 단계도 기대됨
    그 외에는 내 기준에서 이 언어는 기능적으로 100% 완성됐음

    • 마지막으로 Elixir를 봤을 때는 “결국 Erlang도 해야 한다”는 합의가 있는 것처럼 보였음
      지금도 그런가, 아니면 더 이상 Erlang으로 내려갈 필요가 없나?
답변달기