Elm 0.19.2, 빌드 속도 개선

• Elm 0.19.2는 Elm 1.0으로 가기 전 여러 소규모 릴리스로 컴파일러 개선을 반영하려는 흐름의 첫 단계임
• 대규모 Elm 코드베이스에서 처음부터 컴파일은 5.7초, 이후 증분 빌드는 350ms 미만으로 측정돼 개발 중 집중 흐름을 끊을 가능성이 줄어듦
• 이번 개선은 파싱 중 할당을 줄이는 데 집중됐고, 85만 줄 실험에서 GC 복사량 20% 감소, 최대 메모리 사용량 10% 감소, 전체 속도 7% 향상이 관찰됨
• 실제 프로젝트 테스트에서는 개선 폭이 다양했으며, 351개 모듈을 처음부터 컴파일하는 사례는 4.981초에서 2.595초로 줄어 1.9배 빨라짐
• Acadia 작업에서 나온 성능·언어 아이디어가 앞으로 호환성을 깨지 않는 릴리스로 순차 반영되고, 마지막 손질 후 Elm 1.0으로 이어질 계획임

---

Elm 0.19.2에서 빨라진 컴파일

• Elm 0.19.2는 누적된 컴파일러 개선을 Elm에 작은 단위로 반영하는 첫 릴리스임
• 빠른 컴파일러는 개발자가 브라우저 탭으로 전환하며 집중을 잃는 상황을 줄여줌
  • 증분 컴파일이 400ms 미만이면 다른 작업으로 넘어갈 틈이 거의 없어짐
• 85만 줄 Elm 코드 기준 성능은 다음과 같음
  • 처음부터 컴파일: 5.7초
  • 증분 빌드: 350ms 미만
• 실제 변경은 파싱 중 할당을 줄이는 작업에 집중됨
  • GC 복사량 20% 감소
  • 최대 메모리 사용량 10% 감소
  • 전체 속도 7% 향상
• 50만 줄을 넘는 프로그램에서는 완만한 개선을 기대할 수 있고, 더 작은 프로그램에서는 Elm 컴파일러가 여전히 매우 빠른 편임
• 실제 환경 테스트에서는 개선 폭이 프로젝트마다 달랐음
  • 일부 프로젝트는 소폭 개선됨
  • 351개 모듈을 처음부터 컴파일하는 경우 4.981초에서 2.595초로 줄어 1.9배 개선됨
• 새 버전은 Elm compiler 0.19.2 릴리스에서 받을 수 있음

Elm 1.0으로 가는 다음 릴리스들

• Acadia라는 데이터베이스 관련 컴파일러 작업에서 얻은 아이디어가 Elm에도 활용될 예정임
  • Acadia는 현재 비공개 알파 상태임
  • 공개 공유는 올해 말로 예정돼 있음
• Elm에 반영할 아이디어는 성능 개선과 언어 기능을 모두 포함함
  • 예: 더 빠른 파서
  • 예: equatable, hashable 타입
• 이런 변화는 Elm에 자연스럽게 통합하기 위해 호환성을 깨지 않는 작은 릴리스 시리즈로 반영될 예정임
• 마지막 손질 단계에서 Elm 1.0으로 넘어갈 계획임
• Elm을 처음 접하는 사용자는 온라인 예제와 가이드로 시작할 수 있음
• Elm 0.19.2는 패치 릴리스라 기존 프로젝트에서도 새 버전을 내려받아 바로 사용할 수 있음

[GN⁺]

Hacker News 의견들

• 요즘 Elm은 영향력 큰 연구용 언어에 더 가깝게 봄
  초점이 뚜렷하고, 공개 로드맵이나 공식 지원도 없으며, 리더십은 커뮤니티나 코어팀 구축에 거의 관심이 없어 보임
  그래도 작업감은 정말 좋고, 그 결과 여러 포크와 파생 프로젝트가 생겼음. 최근 Gleam 콘퍼런스에서 Louis Pilfold가 “Elm 사용자는 각자 자기 컴파일러를 유지한다”고 농담했는데, 실제로 최소 6개는 있고 지난달에도 2개가 더 발표됨
  Evan이 1.0을 향해 움직이는 건 반갑고, Elm을 “완성된 것”으로 부른 뒤 후계 프로젝트 중 하나가 포크를 통합하고 커뮤니티를 키우는 어려운 일을 맡을 수 있으면 좋겠음
  개인적으로 다음에 Elm 비슷한 것을 찾는다면 Gleam + Lustre를 볼 생각임. 커뮤니티와 설계를 신경 쓰는 유지보수자 조합이 좋아 보이고, 프런트엔드와 백엔드 모두에서 동작함

  • Elm의 궤적은 꽤 이상했지만, 연구용 언어라고 부르는 건 맞는 듯함
    한때는 열성적으로 전파됐고, 블로그 글과 발표가 많았으며 열기와 도입도 상당했음
    그러다 작성자가 사실상 사라졌고 프로젝트가 멈췄음
    물론 자기 프로젝트니까 그럴 권리는 있지만, 처음부터 기대치를 더 잘 설정했어야 한다고 봄. 적극적인 전파는 아이디어 확산에는 도움이 됐지만, 개발자들이 갑자기 버려졌다고 느끼게 만들기도 했음
  • Elm의 가장 좋은 점은 Haskell 같은 느낌이 강하다는 것임. 몇 년 전에 Elm으로 재미있는 것들을 만들었음
    두 번째로 좋은 점은 “컴파일되면 동작한다”는 철학임. 솔직히 Rust 대부분에서도 비슷한 느낌을 얻을 수 있음. Haskell 느낌은 덜하지만 함수형 조상들의 따뜻한 그림자 정도는 있음
  • Gren은 충분히 유능한 후계자로 보였고, 커뮤니티도 활발하고 도움을 잘 줌
  • 나도 그중 하나임. 언어를 확장해서 여러 편의 기능을 넣었고, 본질적으로 적절한 오류 채널과 지워질 수 있는 합 타입을 통한 의존성 주입을 지원하게 했음
    Elm은 좋은 언어지만, Evan은 정말 유용한 것을 만드는 데 관심이 없어 보이고 언어 운영 전반은 엉망임
  • Elm이 워낙 좋기 때문에 사람들이 정체에 실망하는 것 같음. 그런데 그 정체가 Elm을 좋게 만드는 이유이기도 함

• 2023년에 왜 아직도 Elm을 쓰는지에 대해 글을 썼음
  https://taylor.town/elm-2023
  2026년인 지금도 같은 이유로 Elm을 계속 쓰고 있음 :)
  덤으로 Claude가 Elm과는 아주 잘 맞는 것 같음
  https://taylor.town/diggit-000

• 약 2년 전, 좋아하는 언어인 Elm으로 브라우저용 Snake 게임을 ChatGPT 바이브코딩으로 만들어보는 실험을 했음
  당시에는 꽤 거칠었고, 대규모 언어 모델이 Elm을 죽일 수도 있겠다고 결론 내렸음
  지금은 Elm을 프로덕션에서 쓰고 있고, 대규모 언어 모델은 훨씬 좋아졌음. 오히려 Elm은 지금 대규모 언어 모델에 이상적인 언어라서 도입을 늘릴 수도 있다고 봄. 대부분의 언어보다 단순하고, 안정적이며, 언어 안에 의견이 강한 아키텍처가 들어 있어 코드베이스들이 서로 매우 비슷해지기 때문임

  • AI 덕분에 음악에도 더 빠졌고, MIDI 키보드를 사고 제대로 된 DAW 소프트웨어도 설정했음
    Rust로도 더 많이 만들게 됐고 Rust 문서도 더 읽고 있음. 대규모 언어 모델은 그걸 쓰는 대상 자체를 배우지 않을 핑계가 되어선 안 되고, 그런 식이면 나쁜 엔지니어임
    대규모 언어 모델은 받은 결과를 유지보수할 수 있도록 조사하고 배울 시간을 벌어줌. 문제를 이해하고 있으면 프롬프트도 더 잘 쓸 수 있음
  • 대규모 언어 모델이 Elm 도입을 늘릴 수도 있다는 말은 맞기도 하고 아니기도 함
    결국 학습 데이터와 RLHF에 Elm이 얼마나 들어 있느냐에 달려 있음. 구조화된 프레임워크나 언어는 코드베이스가 더 비슷해서 생성이 쉬워진다는 데는 동의함
    하지만 그것만으로는 부족하고, 보통 개발자 도입은 그 자체로 훨씬 복합적인 담론임
  • 개선됐을 수도 있지만, Claude Code 같은 에이전트가 Elm의 의미 있는 공백에서 계속 넘어지는 걸 보고 크게 실망했음
    Python은 아주 잘 다루는데 이상하게 느껴졌고, Elm은 현대 언어 중에서도 가장 안정적인 축임. 너무 안정적이라 변하지 않는다고 불평할 정도니까. 다만 마지막으로 시도한 게 1년 전쯤이라 지금은 나아졌을 거라고 봄
  • 그런 관점은 타당함. 그렇게 생각해본 적은 없지만, 생태계가 앞으로 나아가지 않는다면 여전히 망설일 것 같음

• JavaScript 관련 제한은 해결됐나? 기억으로는 JavaScript와 연동하려면 Elm의 Ports 메커니즘을 써야 했고, 직접 래퍼를 쓸 수 없게 했던 것 같음
  누군가 직접 JavaScript 래퍼나 FFI를 쓸 수 있게 포크하면서 논란도 있었던 것 같음

  • FFI는 여전히 대부분 ports로 처리함. 뷰 쪽은 웹 컴포넌트를 쓰기도 함
    이건 의도적인 선택이고, 1.0까지는 물론 그 이후에도 유지될 가능성이 큼

• 이 프로젝트가 아직 살아 있는 줄은 몰랐음. 비꼬려는 건 아니지만, 이미 끝난 줄 알았음

  • 프로젝트는 죽어 있었음. 이전 릴리스가 7년 전이었고, 창시자가 유지보수를 멈춘 뒤 커뮤니티가 BDFL 모델을 넘어서지 못해서 그대로 멈췄음
    그래서 죽어 있었고, 이제 막 부활한 셈임. 그사이 커뮤니티는 많이 시들었을 것으로 앎
  • 커뮤니티에 깊이 관여하진 않았지만, 당시 참여하던 사람들을 알고 있고, 내가 이해한 바로는 커스텀 중위 연산자 제거가 커뮤니티 지지를 많이 잃게 만들었음
    매우 인기 있던 기능이었는데 언어 창시자가 싫어한다는 이유로, 커뮤니티가 강하게 유지 요청을 했음에도 제거됐음
    기술적으로는 아마 맞는 결정이었겠지만, 사회적으로는 매우 인기 없었고 아마 잘못된 결정이었다고 봄
  • 다시 돌아와서 반가움. Elm에는 늘 응원하게 되는 놀라운 우아함이 있었음
  • 지난 2년 동안 매우 수익성 좋고 군더더기 없는 회사에서 Elm을 전문적으로 써왔음
    입사 전에는 몰랐지만 React, Redux 등 경험이 있어서 빠르게 배웠음
    Elm 커뮤니티라면 이걸 기능이라고 부를 것임. 6~8년 전에 쓴 React 코드 중 오늘날의 React 도구체인에서 완전히 동일하게 잘 동작하는 게 얼마나 될까?
    가치관이 완전히 다름. 2026년의 좋은 React 코드는 2016년 이후 컴파일되는 Elm 코드와 비슷해 보임
  • 나도 Elm 주변 커뮤니티는 사실상 사라졌다고 생각했음. 그래도 단독 유지보수자이자 창시자는 아직 있는 듯함
    Elm은 튜토리얼 말고는 써본 적이 없지만, 최근에는 Gleam 풀스택 앱을 만들었고 대부분 코딩 에이전트를 활용했음. 초반에는 코드 구조를 꽤 엄격히 통제했는데, 그 과정이 꽤 잘 맞았음

• Elm 1.0보다 Elm 0.19 이후가 더 궁금함. 0.19가 Elm 작성자가 공식 승인하지 않은 모든 네이티브 모듈을 막아버린 버전이었고, 내가 보기엔 그게 사실상 Elm의 끝을 표시했음

• 1.0으로 가는 발표로 이보다 더 나쁜 건 떠올리기 어려움. 누가 신경 쓰나? 현지화나 접근성 지원이 없다면 UI 프레임워크를 프로덕션 준비 완료인 1.0이라고 부르는 건 말이 안 됨
  서드파티 기여자가 브라우저 API를 연결할 수 있는 범위를 제한한 것이 장난감 프로젝트를 제외한 Elm의 추진력을 죽였다고 봄
  지금은 프로덕션용이라기보다 Evan이 컴파일러 아이디어를 갖고 노는 샌드박스처럼 보임

  • 그 말은 정확하지 않다고 봄. 내가 유지보수하는 Elm 앱은 완전히 현지화되어 있고, 접근성도 꽤 괜찮다고 생각함
    현지화는 언어별로 큰 레코드 하나를 두고, 문자열을 쓰는 앱의 각 부분에 전달하는 방식으로 처리함. 복수형이나 언어별 특수한 경우에는 레코드 안에 단순한 함수를 넣을 수 있어 아주 편리함
    접근성은 좋은 HTML, ports, 그리고 자동완성 typeahead 같은 복잡한 경우에는 웹 컴포넌트를 조합해서 달성함
  • 그냥 만들게 두면 됨. 진짜 아는 사람들은 준비됐을 때 알아볼 것이고, 유행에 끌리는 사람들은 어차피 구제할 수 없음
  • 한편으로는 Evan이 잘 지내는 걸 보니 좋음. 언어 개발에 대해 꽤 좋은 아이디어가 있고, Elm은 아주 흥미로운 프로젝트들에 많은 영감을 줬음
    다른 한편으로는 7년 동안 아무것도 없다가 작은 컴파일러 성능 개선 하나를 내고 “1.0으로 가는 길”이라고 부르는 건 좀 그렇다. 악의는 없지만 왜 굳이? 이미 죽었고, 애도도 끝났고, 오래전에 다들 떠났음
    정말 놀라운 릴리스가 나오기 전까지는 많은 사람이 신경 쓰지 않을 것 같음

• Evan이 무언가를 가리키고 있는데, 모두가 손가락만 보고 있는 것 같음. 이건 사실 Elm 자체가 아니라 Acadia 준비에 관한 일이라고 봄
  그의 발표 Economics of Programming Languages https://www.youtube.com/watch?v=XZ3w_jec1v8에서 지난 7년간 작업해온 것을 살짝 공개함. 함수형 아이디어를 적용한 질의 언어임
  그는 웹 앱에서 타입 정보가 보통 깨지는 경계를 짚음. 언어와 저장소 사이, 저장소와 전송 사이임
  이 경계들 너머로 타입 정보를 보존할 수 있다면 무엇을 얻을까? 그가 든 답 중 하나는 더 쉬운 마이그레이션임. 손으로 SQL을 쓰는 대신 타입 차이로 처리할 수 있음
  그래서 올바른 질문은 Elm에 들어가는 변경을 보고 Acadia가 어떤 모습일지 추론할 수 있느냐라고 봄. 증분 컴파일은 질의 언어에 무엇을 제공할까?

  • Elm의 역사를 생각하면, 왜 Arcadia가 똑같이 되지 않을 거라고 믿어야 하나?
    아이디어가 아무리 좋아도 Arcadia에 더 미래지향적이고 커뮤니티 중심 개발 모델이 없다면 아무도 채택하지 않을 것임. 잘해봐야 “XYZ에 영감을 준 프로젝트”가 될 뿐임
    Evan은 이것이 다음 거대한 무언가라고 생각할 수 있고 실제로 맞을 수도 있지만, Elm 이후의 세상이 충분히 귀 기울일지는 모르겠음

• 특정 언어 기능을 Elm 팀만 쓸 수 있게 했던 건 철회했나? 그건 언어를 죽일 만한 결정처럼 보였음

• Elm이 추진력을 많이 잃었다고 보는 게 맞나? 이제 HN에서도 거의 논의되지 않고, 릴리스와 소식 간격이 큰 이유 중 하나인지 궁금함
  릴리스 간격을 보면 0.19.2 “Faster builds, and the Road to Elm 1.0”은 2026년 7월이고, 0.19.1 “Friendly syntax hints, faster builds”는 2019년 10월임

[GN⁺]

Lobste.rs 의견들

• 와! Elm 0.19.1이 2019년 10월 21일에 나왔으니 벌써 7년 전이고, 그게 Elm 개발에 관한 마지막 공개 소식이기도 했음
  프로젝트에서 새 소식을 보니 꽤 반가움

  • Evan이 v1 릴리스를 계획 중이라니 정말 기대됨
  • 나도 이 말을 하러 왔음
    사이드 프로젝트에 Elm을 써봤을 때 정말 즐거웠지만, 밖에서 보기엔 커뮤니티가 좀 잠잠해 보였음. 아주 기대되는 소식임

• Elm은 웹 개발을 재미있게 만들어줬음
  1.0이 무엇을 가져올지 기대됨

• 정말 기분 좋은 깜짝 소식임
  Elm의 안정성을 늘 좋아했고, 1.0도 과격한 변화는 하지 않을 것처럼 보이는데 개인적으로는 좋은 방향이라고 봄

  • 설명된 호환성 깨지는 변경은 꽤 큰 영향을 줄 수 있어 보임
    == 등이 더 이상 아무 타입이나 받지 않게 되면 바꿔야 할 Elm 코드가 꽤 많을 것임. 업그레이드 절차가 어떻게 될지 궁금함

• Elm 업데이트를 보니 반가움
  프로그래밍 언어가 몇 년 동안 아무 업데이트도 없는 건 조금 이례적임. 이유는 이해하지만, 대중의 인식이라는 건 묘한 면이 있음

  • 맞음, 특히 모든 게 미친 속도로 움직이는 프런트엔드에서는 더 그렇다

• 이 소식 좋음
  가끔씩 현대 프런트엔드 개발의 광기에서 벗어나기 좋은 휴식처럼 Elm을 다시 들여다보곤 함

• ZuriHac 2026에서 Evan의 발표를 볼 기회가 있었고, 새 Elm 릴리스가 온다고 암시해서 정말 놀랐음
  영상이 곧 올라오길 바라지만, 안정성을 목표로 하는 방식이 이 업계의 빠른 진전 강박과 잘 맞지 않는다는 걸 이해한 듯했음. 내가 이해하기로 Elm은 더 작고 빠른 단계들을 밟을 수도 있음. 기대되고, 그 발표 덕분에 Elm이 많이 그리워졌음

• equatable과 hashable 타입 같은 더 눈에 띄는 기능을 Elm이 어떻게 다룰지 궁금함
  이 언어의 논쟁적인 설계 선택 중 하나가 타입클래스 같은 더 강력한 Haskell식 타입 시스템 기능을 피한다는 점임. 개인적으로는 자연스럽고 잘 정의된 순서가 있는 커스텀 타입조차 딕셔너리 키로 쓸 수 없다는 게 늘 불편했음. 그래도 Elm 작업이 계속되고 있다니 전반적으로 좋은 소식임

  • 타입클래스식 기능을 너무 기대하진 않는 게 좋을 듯함
    블로그 글의 표현으로 미뤄보면, 현재 있는 제약 타입 변수, 즉 number, appendable, comparable, compappend에 더해 새 제약 타입 변수 몇 개를 추가하는 정도일 것 같다고 상상함