4개월간의 Zig 경험, 무엇이 좋고 무엇이 부족한가
원제 Four Months of Zig
102 포인트댓글 59
Key Point
Zig가 점점 성숙해지면서 실제 프로덕션 프로젝트에서 사용 가능해지는 시점, 안정화 전 남은 과제들이 무엇인지 개발자 관점에서 명확히 정리된 평가이다.
핵심 요약
- 저자는 4개월 만에 Zig로 돌아와 snurl(작은 네트워크 프로토콜용 라이브러리), TUI 타이퍼 레이서, n-body 시뮬레이터 등 여러 프로젝트를 진행했다.
- Zig Day Seattle에서 Zig의 창시자 Andrew Kelley를 만나고 다른 개발자들과 협업하면서 커뮤니티의 가치를 느꼈다.
- anyzig 도구로 여러 Zig 버전을 쉽게 관리할 수 있으며, 명시적 IO와 allocator 파라미터 설계가 메모리 관리를 명확하게 한다고 평가했다.
- Zig의 빌드 시스템은 우버 같은 회사도 채택할 정도로 우수하며, 의존성 문화(최소화)로 인해 대부분의 프로젝트가 1~2개의 직접 의존성만 가진다.
- 에러 처리는 Rust보다 간편해서 try 키워드 사용이 panic보다 훨씬 쉬우며, 증분 컴파일은 x86_64 Linux/macOS에서 매우 빠르다.
- 표준 라이브러리 안정성 부족으로 버전 업그레이드 시 주기적인 변경이 필요하며, 1.0 출시 전까지 이는 지속될 예상이다.
- 수명(lifetime) 관리 지원 부족으로 스택 할당 버퍼를 반환하는 실수가 쉽게 발생할 수 있으며, 컴파일러가 현재 허용하지만 향후 버전에서 깨질 수 있다.
- 문서가 매우 부족해서 표준 라이브러리 TLS 설정 같은 기능을 구현하기 어렵고, 커뮤니티 지식 탐색이 필수다.
- 컴파일 타임에 동작할 수 있는 allocator가 없어서 JSON 파일을 런타임에만 파싱할 수 있고, FixedBufferAllocator 같은 것의 컴파일 타임 지원이 필요하다.
- 부트스트랩 과정에서 WASM 바이너리 blob을 체크인해야 하므로 Debian 같은 배포판이 Zig을 패키징할 수 없으며, 완전한 소스 부트스트랩은 아직 불가능하다.
- 저자는 대안 컴파일러 개발이 1.0 이후에 가능하다고 보며, 현재로서는 Zig의 단순한 설계 덕분에 그것이 가능할 가능성이 있다고 평가했다.
- 저자는 Rust보다 Zig을 선호하며 계속 사용할 계획이고, 이전 Rust 프로젝트인 ReTangled를 Zig로 전환 중이며 직접 기여도 목표로 한다.
- Zig Days 같은 로컬 밋업 형식과 Andrew Kelley의 기여자 온보딩 개선 계획에 기대감을 표했다.