Elixir v1.20: 이제 점진적 타입 언어 - 프로그래밍 언어

v1.20은 다중 코어 환경의 애플리케이션에서 컴파일 시간을 다시 개선했으며, 합성 벤치마크에서 Elixir 빌드 도구가 BEAM 언어 중 가장 빠른 결과를 보임

새 컴파일러 옵션 :module_definition은 module 정의 실행 방식을 기본값 :compiled 또는 :interpreted로 고를 수 있게 하며, mix.exs의 elixirc_options: [module_definition: :interpreted]로 활성화함

:module_definition 옵션은 디스크에 쓰이는 .beam 파일에는 영향을 주지 않고 defmodule 내부 실행 방식만 바꾸며, 대형 프로젝트의 컴파일 시간 개선에 도움이 될 수 있음

집합론적 타입을 활용하는 새 타입 시그니처는 v1.20의 타입 시스템 성능, 재귀 타입, 매개변수화 타입, map key-value 순회 연구가 충족된 뒤 typed struct 정의와 함께 논의될 예정임

반대로 TypeScript는 타입 없는 언어에서 사람들이 해온 온갖 기묘한 패턴을 지원해야 해서, 내가 가장 좋아하는 타입 시스템이 됨

전문 Elixir 개발자로 10년쯤 일해왔고, 타입이 들어오는 걸 오래 기대해왔음. 이번에 그 시작이 실제로 들어온 것이 정말 반가움
다만 v1.20에 들어간 상태가 명세 없는 Dialyzer와 비교해 어떤지 알고 싶음. Dialyzer의 성공 타입(success typing) 접근은 “실패할 수 있는 인자 조합이 있으면 경고”가 아니라 “동작하는 인자 조합이 하나라도 있으면 경고하지 않음”에 가깝다고 이해했는데, Elixir가 여기서 하는 것도 비슷한 줄 알았고 Dialyzer는 크게 유용하다고 느끼지 못했음

아직 운영 중인 10년 된 Elixir 코드베이스에서 무엇을 찾아낼지 궁금함

Elixir의 점진적 타입 시스템 관련 글은 HN에서 몇 번 봤지만 자세히 따라가진 않았음. 이 점진적 타입 시스템이 타입 없는 코드와 비교해 프로그램의 점근적 복잡도를 바꿀 수 있는지 아는 사람이 있는지 궁금함
내가 알기로 대부분의 점진적 타입 시스템, 예를 들어 Racket은 프로그램을 점근적으로 더 느리게 만들 수 있고, 예외도 일부 있음 [1]
[1] https://doi.org/10.1145/3314221.3314627

Elixir의 점진적 타입 시스템은 프로그램의 점근적 복잡도를 바꾸지 못함. 설계상 다른 점진적 타입 시스템에서 느려지는 원인인 정적/동적 경계의 런타임 캐스트를 명시적으로 배제함
대부분의 점진적 타입 시스템은 타입 있는 코드와 없는 코드의 경계를 값이 넘을 때 강제를 삽입함. 예를 들어 리스트의 모든 요소를 검사하거나, 값을 타입 프록시로 감싸는 식임. 하지만 Elixir 팀은 그런 런타임 검사 없이 건전성을 얻기 위해 strong arrows 결과를 발표했고, 컴파일러가 내는 바이트코드는 타입 없는 코드와 의미적으로 동일함

아이러니하게도 비판자들은 타입이 필요하다고 했고, Elixir 팬들은 타입이 필요 없으며 Elixir가 어쩐지 마법 같아서 타입 관련 버그가 안 난다고 했는데, 이제 타입을 넣으니 버그를 찾아주고 있음. 버그 방지에 필요 없다던 거 아니었나? 그래도 좋은 변화임. 예전에 Elixir를 꽤 써봤고 즐거웠지만, 타입 부재에는 동의하기 어려웠음

Elixir를 특별히 깊게 따라가진 않았지만, Erlang 쪽 논의에서 본 건 조금 달랐음. 어차피 실패를 우아하게 처리해야 하니 타입 오류도 이미 갖춰야 하는 실패 복구 장치로 처리하면 된다는 흐름이었음
그 관점에는 동의하지 않지만, “$LANGUAGE는 마법”보다는 훨씬 방어 가능한 주장임

그런 주장을 한 번도 못 봤다고 장담할 순 없지만, 본 기억도 없고 있었다 해도 극소수였을 것임. 실제 반대 논리는 대체로 “타입은 좋지만 비용이 있고, 그 비용이 항상 충분한 수익으로 돌아오진 않을 수 있다”에 가까움 집합론적 타입 이론이 발전하기 전에는 그런 입장이 맞았을 가능성도 있음

JavaScript/TypeScript와 Python에서도 같은 일이 있었음. 때로는 사람들이 믿고 싶은 대로 생각하게 둘 수밖에 없음

생명의 순환임. 동적 타입 언어에는 팬이 생기고, 다른 사람들은 정적 타입이 있으면 훨씬 유용해질 거라고 맞게 말함. 팬들은 이를 개인적으로 받아들이고, 정적 타입은 필요 없다고 말함. 이유는 “어차피 유용하지 않다”, “언어의 정신에 어긋난다”, “그냥 스크립트 언어다”, “디버거 쓰면 된다”, “정적 타입은 생산성을 해친다” 등 다양함
그러다 결국 정적 타입을 추가함. Python, JavaScript, Ruby에서 일어났고, 더 있을 것임

Elixir를 업데이트해도 여러 프로젝트에서 깨지는 변경이 없고, 컴파일러가 공짜로 버그를 찾아주는 게 정말 좋음. 너무 익숙해져 버렸음

이걸 보니 정말 기쁨. 이제 “훌륭한 언어” 수준에 가까워지고 있고, 나에게는 Elixir가 첫 번째 후보임
이미 쓰기 편하면서도 훌륭한 기능을 안정적이고 안전하게 계속 추가하는 다른 언어가 있다면 알려주면 고맙겠음. Go를 숙달하다가 고급 C#을 배우는 쪽으로 넘어왔는데, Go는 좋은 기능 추가가 멈춘 느낌이었음

아, 또 시작이네. 다시 1년 동안 Elixir를 배우게 될 듯함
Elixir의 모든 게 좋지만, 어떤 언어보다도 Elixir는 계속 나 자신을 의심하게 만듦. 내 뇌는 함수형에 맞지 않는 것 같지만, 이 변화 때문에 다시 시도하고 싶어짐
아쉬운 건 생태계가 초보자 친화적이라고 보긴 어렵고, 질문에 답할 때 보통 이미 언어를 많이 안다고 가정하는 경우가 많다는 점임

https://pragprog.com/titles/lhelph/functional-web-developmen...
제목에 속지 말 것. 책의 앞 절반은 그냥 Elixir임
지난 8년 동안 Elixir에 다시 적응할 때마다 이 책을 썼고, 매번 잘 먹혔음. 끝까지 읽은 적은 없음
이런 튜토리얼 프로젝트식 프로그래밍 책이 좋은 책인지 보는 기준 중 하나는, 여러 번 시작했지만 끝까지 가지 않아도 중간쯤에서 이미 내 일을 하러 갈 도구를 갖추게 해주는지임

대학 때 “프로그래밍 패러다임 개관” 같은 수업에서 처음 Haskell을 해봤을 때 이걸 정말 고통스럽게 겪었음. 그때 이미 몇 년 동안 프로그래밍을 해왔는데, 오랫동안 기본이라고 느꼈던 것들을 끝내는 데 그렇게 무력할 수 있다는 게 믿기지 않았음
하지만 뇌가 안 맞아서라기보다는, 명령형 언어에서 쌓은 경험 수준과 순수 함수형 스타일에서는 다시 초보자로 시작한다는 대비 때문이라고 봄
점점 나아질 것임. 함수형 프로그래밍이 편해진 계기는, 내가 넉넉하게 띄어 쓴 Bash “한 줄 명령” 같은 코드를 조합하는 걸 얼마나 좋아하는지 깨달았을 때였음. 데이터가 어떤 모양으로 시작하면 명령으로 덤프하고, 원하는 모양에 더 가까워지는 단계를 생각해 다음 명령으로 파이프하고, 다시 살펴봄. 그렇게 계속하면 끝에는 보통 변경하지 않는 데이터 변환들의 연속이 남음
셸에서 이게 편한 이유 중 하나는 매일 파일 시스템을 돌아다니며 명령 어휘를 쌓기 때문임. Unix 계열 환경에서 익숙한 “함수” 라이브러리는 수년에 걸쳐 꽤 커졌음. 순수 함수형 프로그래밍 환경에서도 같은 일을 해야 하지만 어휘를 배우는 데 조금 더 노력이 듦. 자주 쓰는 “명령”은 grep, cat, sort 대신 map, fold, zip 같은 함수가 됨
하지만 핵심은 정말 같고, 파이프라인을 만드는 매력도 양쪽에 똑같이 적용됨. 조각조각 만들 수 있고, 각 퍼즐마다 이전 단계는 잊고 눈앞의 데이터를 다음에 어떻게 변환할지만 생각하면 됨. 이 낮은 맥락성이 신선하고 편안함
꼭 시도해보고 즐기길 바람. 무언가를 못하는 상태를 즐길 수 있게 될 때, 마침내 잘하게 됨

Rust를 조금 아는지 궁금함. 나도 함수형 언어 경험이 많진 않지만, Gleam은 Rust스러운 부분 덕분에 익숙하게 느껴져서 문법보다 개념에 더 집중할 수 있었음
물론 몇 번 오후를 써본 정도지만, 다시 함수형 언어로 내 뇌를 길들이겠다면 익숙함 때문에 Gleam을 고를 것 같음

ElixirForum에 질문해보길 권함. 진짜 적대적인 반응은 본 적이 없음
가끔 모호해서 관심을 못 받거나, “숙제 대신 해줘” 냄새가 나서 무시되는 글은 있음
하지만 진짜 호기심이 담긴 글은 내가 보기엔 모두 답을 받음

이런 말은 항상 혼란스러움. 상태로 뒤범벅된 객체지향 프로그램이 내게는 훨씬 추론하기 어려움

훌륭함. 1.20에서는 우리 큰 umbrella 앱 컴파일이 꽤 더 빨라진 것처럼 보임

Gleam과 비교하면 어떤지 궁금함. 아니면 이제 왜 Gleam 대신 Elixir를 써야 할까? Phoenix, 특히 LiveView가 Elixir의 큰 매력일 것 같긴 함

Rust를 좋아하느냐, Erlang을 좋아하느냐의 차이임. Gleam을 쓰는 건 Rust를 쓰는 느낌이고, Elixir를 쓰는 건 Erlang을 쓰는 느낌임
Gleam OTP의 현재 상태는 모르지만, 마지막으로 봤을 때는 좋지 않았음
둘 다 상관없고 타입만 중요하다면 Gleam을 쓰면 됨. 그런데 그러면 그냥 Rust를 쓰면 되지 않나?

Gleam 웹사이트에 바로 비교 자료가 있음

Gleam에는 매크로가 없고, Phoenix나 Ecto 같은 많은 Elixir 라이브러리는 매크로를 매우 효과적으로 사용함
예를 들어 Gleam은 JSON 디코딩/인코딩이 장황해지는 문제가 있음. Rust에서는 serde를 derive하면 되고, Elixir에서는 함수 호출 하나면 됨
Elixir는 더 성숙한 생태계를 가짐. 예를 들어 Gleam에서 Phoenix나 다른 Gleam 프레임워크를 쓸 수는 있지만, 경험이 같지는 않음
Gleam이 Elixir보다 끌리는 큰 이유는 타입이고, Elixir가 이제 그 격차를 좁히고 있음. 또 JavaScript로 컴파일할 수 있다는 점도 있는데, Elixir에서는 Hologram이 비슷한 일을 하고 있음
개인적으로는 Gleam의 타입 시스템과 Rust 같은 문법을 더 좋아하지만, 지금은 내 모든 웹 개발 프로젝트에 Elixir가 더 나은 선택이라고 느낌