Crystal은 대중적이지는 않지만 무척 흥미로운 언어임. Ruby 사용자는 아니지만 Go나 Rust 외의 네이티브 컴파일 언어를 찾다가 Nim도 조금 써봤고, 좀 다른 것을 원해 Crystal을 접했는데 상당히 인상적이었음. 아직 다듬을 부분과 자금 지원이 필요해 보이지만, 조건만 달랐다면 탄탄한 언어로 크게 성장했을 것 같음.
LLVM 기반이고, 매우 가벼운 그린 스레드와 C 상호 운용성을 지원하며, 컴파일 시점 매크로로 AST 검사·코드 생성·상용구 제거가 가능함. 웹 프레임워크도 흥미로워 보이며, Ruby 같은 언어에 네이티브 성능을 얻는다는 점이 매력적임.
Nim에는 좀 더 Python다운 일반적인 객체 지향 기능을 원했는데, Ruby에서 출발한 Crystal에는 Go·Rust·Nim을 쓰면서 아쉬웠던 객체 지향 기능이 잘 갖춰져 있음. Ruby가 취향은 아니었어도, Go의 패키지 관리가 정착하기 훨씬 전부터 내가 써본 가장 쾌적한 생태계 중 하나였음.
찾아보니 Crystal의 Windows 지원은 2023년에 시작했으니 비교적 최근임. 언어 보급을 늘리려면 주요 운영체제 세 곳을 가능한 한 빨리 지원해야 한다고 봄. Go도 Windows 지원과 정식 출시를 계기로 크게 성장했음.
일반적인 객체 지향을 원하는 이유가 무엇인지 궁금함. 익숙한 습관을 이어가려는 것인지? 암묵적 null 다음으로 소프트웨어에서 가장 큰 실수라고 봄. Crystal은 괜찮지만, 타입 시스템이 Go만큼 제한적인 언어로는 네트워크 프로그래밍에서 Go를 이기기 어려움.
이제 직접 코드를 쓰지 않게 된 것이 씁쓸함. 이런 것에서 얻던 즐거움이 많이 사라짐.
이번 발표를 보고 몇 년 전 Crystal을 처음 써봤을 때의 설렘이 잠깐 되살아났음. 새 언어를 배우고 이것저것 만져보는 일이 참 즐거웠음.
그런데 코딩 에이전트를 열면 Crystal로 시도해보고 싶은 거의 모든 것을 한 번에 만들어주겠다는 생각에 조금 낙담함. 내게 어떤 언어는 실무용이 아니라 창작과 학습의 공간이었음.
여전히 직접 코드를 쓸 수 있음. 나는 업무에서도 매일 직접 작성함.
나는 여전히 직접 작성함. 다행히 모든 고객이 바이브 코딩한 애플리케이션을 자기 시스템에 풀어놓고 싶어 하지는 않음.
장시간 실행되는 프로그램에 Crystal을 본격적으로 사용한 드문 사람 중 하나일 텐데, 결국 사용을 중단해야 했음. I/O 도중 부적절한 시점에 예외가 발생하면 런타임 전체가 멈추는 고질적인 문제가 있었기 때문임. 몇 년 전 일이라 GitHub 이슈는 바로 떠오르지 않지만, 언어를 다시 설계한다면 예외와 소멸자·finalize는 넣지 않았을 것 같음.
그래도 CLI 개발에는 훌륭한 언어임. 팀이 계속 개발을 이어가고 있어 반가움.
Crystal은 타입이 있는 Ruby에 Go의 성능과 동시성 처리 방식을 결합한 언어라고 보면 됨.
꽤 매력적으로 들림. Ruby는 코드를 작성하기에는 훌륭하지만, 다른 인터프리터 언어와만 비교해도 성능이 너무 낮아서 주목받던 자리에서 밀려난 언어이기 때문임.
최신 상황은 모르지만, Crystal의 스케줄러는 동시성은 늘 잘 처리했어도 병렬성에서는 Go에 크게 뒤처졌음. Go가 인기 있는 이유는 병렬 처리가 뛰어나고 가비지 컬렉터 덕에 비교적 안전하기 때문임.
Crystal이 최근 몇 차례 릴리스에서 개선 중인 것은 알지만, Go 수준의 병렬성을 달성했다면 놀라울 것 같음. Go 런타임은 상당한 공학적 성취이며, Rust에 큰 이점이 여러 개 있는데도 병렬 부하의 최악 구간인 p99에서는 수작업으로 최적화한 Rust보다 빠를 때가 종종 있음.
다만 커뮤니티 규모는 Elm 정도임.
여러 용도로 Crystal을 만족스럽게 사용 중이며, 작은 서버에 배포하기도 편리함. 대량의 실행 추적 데이터를 처리하려고 기존 Ruby 코드를 옮겼더니 코드는 거의 그대로인데 처리 성능은 40배, 메모리 사용량은 3분의 1로 개선됨.
버전마다 나아지는 것도 반가움. 참조 문서는 좀 더 손볼 필요가 있지만 지금도 괜찮은 편임.
Crystal의 가장 큰 불편 중 하나는 컴파일 시간임. 안타깝게도 쉽게 해결할 방법은 없음.
aarch64-linux가 Tier 1으로 승격되어 반가움! 이제 CTO를 설득해 서비스 일부를 Crystal로 옮기고 저렴한 Hetzner 장비에서 돌릴 수 있겠음.
Crystal을 실서비스에서 사용한다니 반가움! 어떤 용도로 쓰고 있는지?
Crystal이 처음 인기를 얻었을 때 자세히 살펴봤지만, REPL을 제거하면서 내게는 Elixir가 더 나은 선택이 됨.
지금은 crystal i 대화형 모드가 있지만, 특정 라이브러리를 사용할 수 없는 등 기능이 충분하지는 않음.
그래도 제대로 개선하기가 아주 어렵지는 않을 듯함. 얼마 전 Claude와 며칠 오후를 들여 JIT REPL을 추가했는데, 기존 컴파일러와 거의 같은 성능을 내고 테스트한 모든 라이브러리에서 안정적으로 작동함. 다만 Crystal은 LLM으로 만든 기여를 원하지 않아서, 흥미로운 실험으로 남겨두고 내 언어를 만들기 시작함.
Crystal을 1년 사용한 뒤 빌드가 더 빠른 Go로 옮겼음. Bun도 빠르게 개선되고 메모리 사용량이 꾸준히 줄어들어 저렴한 서버에 유용할 수 있음.
Crystal을 지금 배울 이유가 있는지? Ruby와 상호 운용되지도 않고, 사용하는 유명 기업도 알지 못함. Ruby처럼 생겼지만 Ruby는 아니고 컴파일 언어라는 것만으로는 왜 배워야 하는지 모르겠음.
지나치게 부정적이고 노골적으로 화를 유도하는 질문이지만 답해보겠음. 얼마 전까지만 해도 사람이 코드를 읽고 이해해야 했다는 사실을 잊은 것인지? Ruby의 성능 특성이나 인터프리터 의존성 없이 Ruby다운 좋은 문법을 쓰고 싶은 수요는 분명 있었음.
주류가 되지 못한 것은 맞지만, 대세가 아니라는 이유로 우리가 해온 모든 프로젝트를 버려야 하는지?
우아하면서 성능 좋은 코드를 작성하기에 좋은 언어이기 때문임. 그것만으로 동기가 충분하지 않다면 본인에게 맞는 언어가 아닌 것 같음.
Crystal은 애초에 Ruby 상호 운용성을 목표로 하지 않았고, Ruby의 편리한 문법에서 영감을 받은 언어임. 좋은 개발 경험과 표준 라이브러리, 자동 메모리 관리, 네이티브 성능을 원한다면 배울 만함. Go를 배우는 이유와 비슷함.
LLM 이전에는 배포 가능한 바이너리가 필요할 때 Crystal을 선택했음. 주로 서버에서 상주하는 에이전트 데몬을 만들었는데 네트워크 기능도 훌륭했음. 사실상 유일한 대안은 Go였지만 별로 좋아하지 않았고, 링크 과정도 더 복잡했거나 적어도 당시에는 그랬음. 타입을 일관되게 사용하면 컴파일 성공만으로도 정상 동작을 꽤 확신할 수 있었고, 지금도 실서비스에서 Crystal 에이전트가 수년째 메모리 누수나 문제 없이 실행 중임.
다만 LLM이 선택 기준을 바꿨음. 이제 언어 자체나 마음에 들지 않는 오류 처리 방식을 직접 다룰 필요가 없어, 라이브러리 지원이 더 좋은 Go를 사용함. 그래도 Crystal에는 여전히 애정이 있음!