Gleam에 관한 자주 묻는 질문과 답변. 이름의 유래, 컴파일 대상, 가변 상태와 부수효과, 타입 클래스와 메타프로그래밍, 메시지 전달의 타입, 핫 코드 리로딩, 0으로 나누기 처리, 다른 언어와의 비교, Elixir 상호운용, 컴파일러, 프로덕션 사용 여부 등을 다룹니다.
Gleam은 “beam”과 운율이 맞고 동의어이며, “beam”은 Erlang 가상 머신의 이름입니다.
또한 대부분의 사람들이 쉽게 쓰고 발음할 수 있길 바라는 짧고 귀여운 단어이기도 합니다.
Gleam은 Erlang 또는 JavaScript로 컴파일됩니다.
타입 클래스는 재미있고 아주 깔끔하고 간결한 API를 만들 수 있게 해 주지만, 이해하기 어려운 코드를 쉽게 만들어내게 할 수 있고, 오류 메시지가 혼란스러워지는 경향이 있으며, 다른 언어에서 그 코드를 사용하기 훨씬 어렵게 만들고, 컴파일 시간 비용이 크며, 컴파일러가 전체 프로그램 컴파일과 비용이 큰 단형화(monomorphization)를 수행하지 않는 한 런타임 비용도 발생합니다. 아쉽지만 이는 Gleam과 잘 맞지 않으며, 도입 계획이 없습니다.
우리는 Gleam의 가독성과 빠른 컴파일을 해치지 않는 범위에서 어떤 형태로든 메타프로그래밍을 도입하는 것에는 열려 있습니다. 메타프로그래밍 설계에 대한 제안이 있다면 GitHub 토론으로 공유해 주세요.
Gleam의 모든 데이터 구조는 불변이며, 구조적 공유를 사용해 구현되어 효율적으로 업데이트할 수 있습니다.
애플리케이션이 어떤 가변 상태를 보유해야 한다면, 액터(재귀를 사용해 가변 상태를 불변적으로 감싸는)를 통해 보유하게 하거나, Erlang의 인메모리 키-값 데이터베이스인 ETS를 사용할 수 있습니다.
Gleam을 JavaScript로 컴파일하는 경우 javascript_mutable_reference 라이브러리를 사용하면 가변 참조를 쓸 수 있습니다.
예. Gleam은 OCaml이나 Erlang처럼 비순수 함수형 언어입니다. 파일 쓰기나 콘솔 출력 같은 비순수 동작도 별도의 처리 없이 수행할 수 있습니다.
나중에 Gleam 애플리케이션의 비순수 코드를 식별하고 추적하기 위한 효과 시스템을 도입할 수도 있으나, 이는 아직 연구가 진행 중인 영역입니다.
타입 안전한 메시지 전달은 Gleam의 코어 언어 기능이 아니라 라이브러리 집합으로 구현되어 있습니다. 이렇게 하면 메시지 전달에 타입을 부여하는 단 하나의 접근 방식에 얽매이지 않으면서도 Erlang의 OTP 프레임워크를 활용해 안전한 동시성 프로그램을 작성할 수 있습니다. 메시지 전달의 타이핑은 활발히 연구되는 분야이므로, 미래에 더 나은 접근 방식을 발견할 수도 있는데, 이런 비고착성은 중요합니다!
더 보고 싶다면 Gleam의 OTP 라이브러리를 확인해 보세요.
일반적인 Erlang의 코드 리로딩 기능은 모두 작동하지만, 이미 실행 중인 코드의 타입을 알 방법이 없기 때문에 업그레이드 자체를 타입 체크하는 것은 불가능합니다. 따라서 Gleam이 제공할 수 있는 수준이 아니라, 통상적인 Erlang 수준의 안전성을 갖게 됩니다.
일반적으로 Gleam용 OTP 라이브러리는 업그레이드보다는 타입 안전성에 최적화되어 있으며, atom 모듈 대신 레코드를 사용하므로 상태 업그레이드 콜백을 작성하는 일이 더 복잡할 수 있습니다.
프로그래밍 언어에서 0으로 나누기를 처리하는 일반적인 방법은 세 가지가 있습니다:
Infinity 값을 반환한다.0을 반환한다.Gleam은 암묵적으로 예외를 던지지 않으므로, 예외를 던지는 방법은 선택지가 아닙니다. BEAM VM에는 Infinity 값이 없으므로 이것도 선택지가 아닙니다. 따라서 Gleam은 0으로 나눌 때 0을 반환합니다.
표준 라이브러리는 0으로 나누기를 Result 타입으로 반환하는 함수를 제공하므로, 프로그램에 더 적합하다면 이를 사용할 수 있습니다.
0으로 나누기에 대한 수학적 관점의 자세한 내용은 Hillel Wayne의 이 글을 참고하세요.
Alpaca는 ML 계열 언어에서 영감을 받은, Erlang VM을 위한 정적 타입 언어라는 점에서 Gleam과 비슷합니다. 훌륭한 프로젝트이며 Gleam에 초기 영감을 주기도 했습니다!
다음은 차이점의 비포괄적 목록입니다:
Caramel도 Erlang VM을 위한 정적 타입 언어라는 점에서 Gleam과 비슷합니다. 특히 OCaml 계보 덕분에 아주 멋진 프로젝트죠!
다음은 차이점의 비포괄적 목록입니다:
Elixir는 Erlang 가상 머신에서 실행되는 또 다른 언어입니다. 매우 인기 있고 훌륭한 언어입니다!
다음은 차이점의 비포괄적 목록입니다:
fun.() 같은 특별한 문법이 없습니다).무엇보다도 둘 다 BEAM 언어입니다! 개인적으로 가장 즐겁고 생산적이라고 느끼는 프로그래밍 스타일의 언어를 쓰시길 권합니다.
Purerl은 Erlang을 출력하는 PureScript 컴파일러의 백엔드입니다. PureScript도 Purerl도 모두 환상적입니다!
다음은 차이점의 비포괄적 목록입니다:
Rust는 C나 C++처럼 네이티브 코드로 컴파일되며 프로그램의 메모리 사용을 완전히 제어할 수 있는 언어입니다. Gleam의 컴파일러도 Rust로 작성되었습니다! 우리는 이 언어의 큰 팬입니다.
문법적으로 약간의 유사성이 있긴 하지만, Gleam과 Rust는 서로 매우 다른 언어입니다.
예! Gleam 빌드 도구는 Elixir를 지원하며, Gleam 프로젝트에서 Elixir 의존성과 Elixir 소스 파일을 함께 컴파일할 수 있습니다. 이를 위해서는 컴퓨터에 Elixir가 설치되어 있어야 합니다.
Elixir 매크로는 Elixir 외부에서 호출할 수 없으므로, 일부 Elixir API는 Gleam에서 직접 사용할 수 없습니다. 이런 API를 사용하려면 매크로를 사용하는 Elixir 모듈을 작성한 뒤, 그 모듈을 Gleam 코드에서 사용하면 됩니다.
Gleam 컴파일러의 프로토타입은 Erlang으로 작성되었지만, 정적 타입의 부재로 인해 리팩터링이 느리고 오류가 발생하기 쉬운 과정이 되어 Rust로 전환했습니다. 프로토타입을 Rust로 완전히 다시 작성하면서 많은 기술 부채와 버그를 제거할 수 있었고, 성능 향상도 덤으로 얻을 수 있었습니다!
커뮤니티가 언젠가 Gleam으로 작성된 Gleam 컴파일러를 구현할 수도 있겠지만, 코어 팀은 지금은 라이브러리, 도구, 문서화 같은 에코시스템의 다른 영역 개발에 집중하고 있습니다. 이 편이 전체적으로 더 큰 가치를 제공하기 때문입니다.
네!
Gleam은 프로덕션 준비가 된 프로그래밍 언어이며, 실행 대상인 Erlang과 JavaScript 런타임은 매우 성숙하고 실전에서 검증되었습니다. Gleam은 미션 크리티컬한 워크로드에도 준비되어 있습니다.
Gleamlins, Gleam Discord 서버에 따르면요.
네, 그렇게 생각해요. :)