엘릭서, 점진적 타입 시스템을 도입한 언어로 발전
(twitter.com/josevalim)- Elixir가 첫 커밋 이후 13년을 맞는 시점에 공식적으로 점진적 타입 지정 언어로 전환
- 현재 bitstring에 대해 타입 추론 및 타입 검사를 수행하며, 모든 타입을 지원(단, 타입 간 서브타이핑(sub-typing) 은 아직 미지원)
- 첫 번째 마일스톤은 패턴(patterns)과 가드(guards) 에 대한 추론 수행
- 이 추론은 언어나 기존 코드베이스를 변경하지 않고도 버그를 잡아내는 방식으로 동작
- Elixir v1.17까지 모든 패턴과 가드의 추론을 완성하는 것을 목표로 설정
점진적 타입 지정 언어 전환 발표
- Elixir 저장소(repo)의 첫 커밋 이후 13년이 되는 시점에 맞춰, Elixir가 공식적으로 점진적 타입 지정 언어임을 발표
- 현재 시점 기준 타입 검사 구현 범위
- bitstring에 대한 타입 추론 및 타입 검사 수행
- 모든 타입(all types) 을 이미 지원하되, 타입 내부의 서브타이핑은 미지원
향후 목표와 첫 마일스톤
- Elixir v1.17까지 모든 패턴(patterns)과 가드(guards) 의 추론을 수행하는 것을 목표로 설정
- 첫 번째 마일스톤은 패턴과 가드에 대한 추론 수행
- 언어나 사용자의 코드베이스를 변경하지 않고도 코드 내 버그를 잡아내는 방식
- 첫 단계가 모두에게 win-win이 되도록 하는 것을 지향
댓글과 토론
Hacker News 의견들
-
좋음. Elixir에 타입이 없다는 점이 일부에게는 장벽이었고, 언어가 대체로 완성된 지금이 타입을 추가하기에 딱 좋은 시점으로 보임
Ruby에서는 Sorbet이 “동적 언어의 철학에 반한다”는 느낌이라 설득되지 않았지만, 일부 영역에서 안전성을 더하는 층으로는 괜찮았음. 거친 부분은 있어도 Elixir 쪽은 타입을 제대로 해낼 것 같음- 게다가 Sorbet은 쓰기 정말 번거로움
-
이 변화가 정말 반가움. 최근 이직한 회사에서 Elixir를 주 언어로 쓰고 있는데, TypeScript에서 오다 보니 타입 있는 언어의 장점과 프로젝트 어디서든 데이터 모델에 접근할 수 있는 점이 많이 그리웠음
Elixir도 이미 훌륭했지만 이건 큰 개선이고, 작업한 팀에게 축하를 보냄- 최근 이직한 회사에서 Elixir를 쓴다니 부럽다
-
https://nitter.net/josevalim/status/1744395345872683471
- nitter는 처음 알았는데, 계정 없이 Twitter를 검색할 수 있어 좋아 보임
몇 달 전 계정을 지웠는데, 더는 유의미한 정보를 찾기 어려웠고 탐색 경험도 너무 불편했음
- nitter는 처음 알았는데, 계정 없이 Twitter를 검색할 수 있어 좋아 보임
-
Jose Valim은 타입 시스템을 제대로 구현할 수 있다고 믿는 업계의 몇 안 되는 사람 중 하나임. 다른 한 명은 Anders Hejlsberg임
- Valim은 전문가들과 협업해 Elixir 관련 작업을 이끄는 능력이 뛰어나 보임
Genetic Algorithms in Elixir의 저자인 Sean Moriarty와 협업해 Nx로 이어졌고, 이번에는 점진적 타입을 구현하기 위해 프로그래밍 언어 연구자인 Dr. Castagna와 박사과정 Guillaume Duboc을 영입했음 - 정확히 왜 그렇게 믿는지 모르겠음. 아는 한 그는 타입 시스템 구현 경험을 입증한 적이 없음
딱히 나쁜 선택이라고 보지는 않지만, 왜 특별히 좋은 선택인지도 이해가 잘 안 됨 - Hejlsberg는 흥미로운 예임. 원래 TypeScript 타입 시스템이 안전하지 않았던 걸 그가 만든 건지, 아니면 다른 사람이 만든 걸 그가 수습한 건지 궁금함
- Valim은 전문가들과 협업해 Elixir 관련 작업을 이끄는 능력이 뛰어나 보임
-
이 소식이 기쁨. Phoenix와 그 전의 RoR은 생산성이 엄청나다는 걸 보여줬지만, 타입과 런타임 오류 문제 때문에 쉽게 깨질 수 있었다고 봄
타입은 다양한 런타임 오류를 빌드 시점 오류로 옮겨줄 수 있고, 신뢰성 있는 소프트웨어에는 큰 장점임 -
정말 기대됨. 한동안 Elixir를 썼고 언어는 좋아했지만 Dialyzer를 쓰는 데 지쳐서 다른 타입 언어로 옮겼음
이 작업이 끝나면 돌아올 생각임. 웹 앱을 작성할 때 Elixir는 다른 언어보다 거의 모든 면에서 더 낫다고 봄- TypeScript에서 Elixir 사이드 프로젝트로 넘어왔는데, 처음에는 Dialyzer가 좀 “멍청하고” 느리게 느껴졌음
충분히 정밀한 타입을 쓰기 어렵고 이상한 것들로 자주 불평했음
프로젝트가 복잡해지고 Elixir를 더 배우면서 Dialyzer가 점점 더 유용해졌음. TypeScript에서 이상한 타입 오류를 쫓다 보면 대개 타입 정의가 충분히 정확하지 않아 고쳐야 했지만, Dialyzer의 이상한 경고를 따라가다 보면 실제 코드 버그를 발견하는 경우가 많았음
복잡한 것들을 그렇게 잘 추론하는 걸 보면 가끔 놀라움. 다만 오류 메시지는 보통 매우 혼란스럽고, 경험이 쌓이면 어느 정도 해결됨
지금까지의 차이는 Dialyzer가 내 타입이 아니라 코드의 버그를 찾아준다는 점이고, 꽤 마음에 듦. Elixir 내장 타입 시스템이 더 빠르고 오류 메시지도 좋아진다면 매우 만족할 것 같음
- TypeScript에서 Elixir 사이드 프로젝트로 넘어왔는데, 처음에는 Dialyzer가 좀 “멍청하고” 느리게 느껴졌음
-
https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradua... 이후로 진행이 정말 빠름
- Elixir는 동적 언어 중에서도 이미 정적인 성격이 강한 편이라 빠른 진척이 크게 놀랍지는 않음
언어 자체가 거의 그런 방향에 맞게 만들어져 있어서, Ruby나 JavaScript에 타입을 붙이는 것보다 훨씬 쉬움
- Elixir는 동적 언어 중에서도 이미 정적인 성격이 강한 편이라 빠른 진척이 크게 놀랍지는 않음
-
PHP에서 배웠으면 좋겠음. PHP의 점진적 타입은 매우 실용적임
- Elixir, 그리고 그 전의 Erlang은 패턴 매칭과 오버로드되지 않은 연산자를 통해 본질적으로 늘 점진적 타입을 갖고 있었음
다만 지금까지는 런타임에 잡혔고, 이번 변화는 그 검사를 컴파일 시점으로 가져오는 것임 - PHP의 “타입 시스템”은 결코 좋은 편이 아님
- Elixir, 그리고 그 전의 Erlang은 패턴 매칭과 오버로드되지 않은 연산자를 통해 본질적으로 늘 점진적 타입을 갖고 있었음
-
Ruby에 내장되길 바랐던 노력이 바로 이런 것임. 많은 Ruby 개발자들이 이제 Elixir를 하는 것도 놀랍지 않음
Elixir는 정말 훌륭한 언어로 다듬어지고 있음