Hacker News 의견들
  • Gleam은 정말 아름다운 언어임. Elixir가 타입 시스템 면에서 이런 방향으로 발전했으면 좋겠다는 생각을 함
    Gleam도 Erlang VM인 BEAM 위에서 동작하며, 덕분에 동시성과 큐 처리가 매우 쉬움
    생태계도 훌륭함. 다만 LLM 시대 이후로 2021년 이후의 언어 발전이 멈춘 것 같아 걱정됨
    그래도 Gleam이 그 문 닫히기 직전에 잘 들어왔고, 곧 LLM들도 따라잡을 거라 기대함

    • 왜 LLM이 언어 발전을 멈추게 한다고 생각하는지 궁금함. 최신 모델들은 올해까지의 지식을 포함하고 있고, 새로운 언어도 예시 몇 개만 있으면 꽤 잘 배움
      언어들이 문법적으로나 철학적으로 완전히 다를 수는 없으니까 큰 문제는 아닐 것 같음
    • Gleam이 OTP 위에 만들어졌다는 건 정확하지 않음. Erlang VM은 BEAM이고, OTP는 Erlang의 라이브러리와 설계 원칙 모음임
      Gleam은 자체적으로 타입 안전한 OTP 서브셋을 제공함. 관련 라이브러리는 gleam-lang/otp 참고
    • 맞음, Erlang VM은 BEAM이고 OTP는 아님. Gleam의 OTP 구현은 Elixir나 Erlang만큼 완성도 높지는 않음
    • 나도 최근 Elixir로 LLM 기능을 포함한 프로젝트를 처음 만들어봤는데, 오히려 이런 흐름이 언어 채택을 촉진할 수도 있다고 느낌
    • Elixir도 점진적으로 set-theoretic typing을 도입 중임. 관련 문서: gradual-set-theoretic-types
  • 올해 Advent of Code를 Gleam으로 풀어봤는데 꽤 인상 깊었음
    장점으로는 성능이 좋고, 언어 서버가 놀라울 정도로 강력함. 자동 포맷팅, 자동 import, 패턴 매칭 보완 등 개발 경험이 훌륭함
    단점은 포매터가 지나치게 세로로 코드를 늘리고, 단순함을 중시하다 보니 list.map처럼 반복 입력이 많음. 또 라이브러리 생태계가 아직 부족함

    • 나도 성능에 놀랐음. C만큼은 아니지만 예상보다 훨씬 빠름. 언어 서버도 거의 모든 IDE에서 잘 작동함
      list.mapimport gleam/list.{range, map} 식으로 줄일 수 있음. C 라이브러리 포팅도 흥미로울 듯함
    • 단점들은 감수할 만하지만, if/else나 guard가 없어서 불편함. 불리언 분기 처리가 너무 장황해짐
    • F#로 AoC를 했는데 비슷한 느낌이었음. List.map 같은 네임스페이스 반복이 탐색성(discoverability) 을 떨어뜨림
    • 인자 포매팅은 아마 Prettier 알고리즘 때문일 것임. 그래도 clang-format의 binpacking보다 훨씬 낫다고 생각함
  • Gleam을 좋아하지만, 재귀 함수 호출 제약이 아쉬움. 내부 함수 호출이 자유롭지 않음
    문법적으로는 Scheme보다 덜 우아하고, 개념적으로는 Erlang보다 단순함. 그래도 정적 타이핑은 장점임
    OCaml도 써봤지만 opam의 lock 파일 문제 등으로 환경 재현성이 떨어졌음. SML 생태계가 더 컸으면 좋겠다는 생각임

    • 나도 비슷한 생각임. Haskell은 이론적으로는 멋지지만, 단순한 hello world도 리소스 소모가 큼
      Idris 2는 의존 타입과 우아한 설계를 갖췄지만 생태계가 작고, PureScript는 Haskell보다 실용적이지만 JS 런타임에 묶여 있음
    • ML 계열을 좋아한다면 ReScript v12를 추천함. OCaml과 Gleam 사이의 균형 잡힌 위치에 있음
  • echo 기능을 보며 디버거에 이런 중간 결과 확인 기능이 기본으로 있었으면 좋겠다고 느낌
    배열 슬라이스나 필터 체인 중간 결과를 코드 수정 없이 볼 수 있으면 좋겠음
    또 2차원 배열을 그리드로 쓰는 건 비효율적이라 생각함. 1차원 배열 + 경계 정보가 더 안전하고 효율적임

  • Gleam은 잘 모르지만 list.map(fn(line) { line |> calculate_instruction })
    그냥 list.map(calculate_instruction)으로 쓸 수 있지 않나 싶음

    • 맞음, 나도 종종 더 복잡한 처리를 하다 지우고 저 형태를 남겨둔 적이 있음
    • 네, 그게 맞음
  • Gleam은 훌륭한 언어임. 나에겐 크게 와닿진 않았지만, 사람들이 즐기는 걸 보니 반가움
    Gleam + Lustre 조합이 새로운 Elm이 될 수도 있겠다는 생각을 함

    • 백엔드 개발자로서 Elm은 매력적이었지만, 창작자와의 갈등과 릴리스 중단으로 멀어졌음. 그래도 그 아키텍처는 다른 프로젝트에서도 유용했음
    • 나도 최근 Gleam + Lustre로 작은 앱을 만들어봤는데, Elm + PostgREST보다 훨씬 잘 됐음. 이제 더 큰 프로젝트에도 쓸 예정임
    • Lustre를 살펴봤는데 생태계가 아직 작음. 인증 관련 예시도 없어서 LiveView로 갔음. 그래도 ergonomics가 좋아서 성장하길 바람
  • 요즘 LLM 시대에 새로운 언어를 배워야 할 가치가 있을지 고민됨
    LLM이 학습하지 않은 언어라면 도구로서의 효용이 떨어질까 걱정임

    • 장기적으로 LLM이 새로운 언어를 학습하지 못한다면, 일반 지능으로서의 목표에 실패한 것임
    • 1~2년 전엔 그런 우려가 있었지만, 지금은 Claude Code가 Elixir 코드도 꽤 잘 씀. 학습 데이터가 적어도 문제없음
    • Claude는 Gleam도 잘 다룸. 문서와 진단 메시지 품질이 좋아서 LLM이 배우기 쉬움. Rust 수준의 진단을 제공함
      반면 Swift는 문법이 복잡해 LLM이 다루기 어려움
    • 언어를 도구로 본다면, 시장 수요 부족이 더 큰 제약일 수도 있음
    • 새로운 언어들이 LLM의 한계 때문에 멈추지 않길 바람
  • 예전에 Gleam을 봤을 때 동적 디스패치(interface나 type class)가 없어 보였는데, 지금은 어떤지 궁금함

    • 보통 “함수 구조체를 전달하라”는 식으로 해결함. 명시적 접근이라 오히려 제네릭의 복잡함에서 자유로워 좋음
    • Gleam은 일급 함수를 지원하므로 동적 디스패치가 가능함. type class나 interface는 결국 고차 함수로 풀 수 있음
  • [first, ..rest][first, second]는 가능하지만 [first, ..middle, last]는 안 됨.
    아마 비용이 비싸서 의도적으로 막은 것 같음

  • 다행히도 블로그 제목 경찰이 빠르게 출동했음
    관련 링크