Crystal 1.22.0, aarch64-linux를 Tier 1으로 승격
Crystal 1.22.0 Is Released
Crystal 1.22.0이 33명의 기여자가 만든 251개 변경 사항과 함께 공개됐다. aarch64-linux-gnu와 aarch64-linux-musl이 공식 빌드 확보로 Tier 1에 올랐고, 모든 타깃이 libevent 없이 시스템 셀렉터 기반 네이티브 이벤트 루프를 기본 사용한다. DWARF 파싱은 온디맨드 스캔과 인덱스 테이블, LRU 캐시로 재설계돼 성능과 메모리 사용이 개선됐다.
Crystal은 STDOUT이나 STDERR 쓰기가 EPIPE로 실패하면 즉시 프로세스를 종료한다. 이는 SIGPIPE 신호의 기본 동작과 매우 유사하다.
HN 토론
77- giancarlostoro
Crystal은 가장 인기 있는 언어는 아닐지 몰라도, 제게는 매우 흥미롭습니다. 저는 Ruby 사람은 아니지만, Go나 Rust 같은 것 말고 네이티브 컴파일되는 다른 언어들을 살펴보고 있었습니다. Nim을 좀 만져봤지만, 뭔가 조금 다른 걸 시도해보고 싶었고, 솔직히 감명받았습니다. 아직 약간 다듬어질 필요가 있고, 더 나은 자금 지원이 도움이 될 수도 있겠지만, 다른 타임라인에서 적절한 조건이었다면 Crystal이 정말 탄탄한 언어로 자리 잡을 수 있었을 거라고 진심으로 생각합니다. LLVM 기반이고, (엄청나게 가벼운) 그린 스레드를 갖추고 있으며, C 상호운용성과 AST 검사, 코드 생성, 상용구 코드 제거를 위한 컴파일 타임 매크로 시스템도 있습니다.
웹 프레임워크들도 흥미로워 보이지만, 아직 깊이 파보지는 않았습니다. 네이티브 성능을 갖춘 Ruby 같은 언어를 얻는 것은 정말 흥미롭습니다.
Nim에서 제가 원했던 한 가지는 좀 더 Python스러운 점, 즉 일반적인 OOP였습니다. Crystal은 Ruby에서 가져왔기 때문에(원래 Ruby로 작성되었다가 셀프 호스팅이 되었다고 알고 있습니다) Go, Rust, 심지어 Nim을 쓸 때 그리워하는 제정신의 OOP 기능을 갖추고 있습니다.
다른 타임라인에서는 Crystal이 뭔가 될 수 있었을 거라고 정말 느낍니다. 또한 "Ruby"라는 것이 어떤 사람들에게는 좋지 않은 인상을 남긴다고 느끼지만, Ruby는 대부분의 사람들이 생각하는 것만큼 형편없지 않습니다. 저에게 맞는 언어는 아니었지만, Go가 패키지 관리 상황을 정리하기 훨씬 전부터 제가 작업해본 가장 멋진 생태계 중 하나였습니다.
편집: 한 가지 생각 더: Windows 설치 프로그램 / Windows s[…]
- burlesona
우리가 더 이상 코드를 작성하지 않는다는 게 슬픕니다. 그것이 이런 것들의 즐거움을 많이 앗아갑니다.
- rubiquity
장기 실행 프로그램에 Crystal을 실전에서 써본 몇 안 되는 사람 중 하나일지도 모르지만, 안타깝게도 런타임의 오랜 문제 때문에 포기해야 했습니다. I/O 도중 잘못된 시점에 예외가 발생하면 런타임이 멈춰버리는 문제였습니다. 몇 년 전 일이라 GitHub 이슈 번호는 이제 기억나지 않습니다. 만약 언어를 다시 설계할 수 있다면 예외와 소멸자/finalize를 넣지 않았을 거라고 생각하고 싶습니다.
CLI에는 정말 좋은 언어입니다. 팀이 여전히 나아가고 있는 모습을 보니 기쁩니다.
- todotask2
Go로 넘어가기 전에 1년 동안 Crystal을 사용했습니다. Go는 빌드 시간이 더 빨라서 좋아합니다. Bun도 빠른 속도로 계속 개선되고 메모리 사용량을 꾸준히 줄여서 예산 서버에서 유용할 수 있습니다.
- sumnole
모르는 분들을 위해: Crystal은 Go의 성능과 동시성 흐름을 갖춘 타입이 있는 Ruby 같은 언어입니다.