무엇이 Zig 프로그래밍 언어를 독특하게 하는가?
(erikexplores.substack.com)- 전문가들은 "컴파일시에 실행할 수 있는 코드"는 "멍청한 아이디어" 라고 지적했지만,
Zig를 만든 Andrew Kelley는 계속 나아가서 구현을 했음 - 몇년 후 이것은 Zig의 킬러 피쳐중 하나가 되었음
- Zig에서 comptime 이라고 부르는 것은 컴파일시에 실행해야 하는 코드
- Zig 개발자는 컴파일중에 Zig코드를 실행 가능한 것을 이용해서 제네릭/템플릿을 지원하지 않아도, 제네릭 코드를 작성하고 메타프로그래밍을 수행 가능
첫 문단부터 문제가 있군요... 프로그래밍 언어 쪽에서 컴파일 시간 계산은 이른바 멀티 스테이지 프로그래밍이라고 하여 메타 프로그래밍을 구현하는 방법 중 하나입니다. 멍청한 아이디어가 전혀 아닙니다.
멀티 스테이지 프로그래밍을 "어쩌다" 구현해 버린 C++ 같은 언어들은 각 스테이지(이 경우 컴파일 시간과 실행 시간)에서 코드가 극적으로 달라지는 문제가 생기는데(C++는 이제 constexpr가 있지만 여전히 이리 저리 부족하죠), Zig는 처음부터 멀티 스테이지 프로그래밍을 염두에 두고 언어를 설계해서 컴파일 시간과 실행 시간에 거의 같은 코드를 쓸 수 있다는 장점과 컴파일 시간에 예측할 수 있는 사항이 별로 없다는 단점을 함께 지니게 되었습니다.
그러니까.... 피할 수 없는 유낫테스트를 통해 컴파일 시에 먼저 돌려보고,
런타임 에러가 될만한 것을 컴파일 에러로 땡겨온다... 정도로 이해하면 될 것 같네요.
대충 문서나 문답을 봤을 때, drop-in으로 c를 대체할 수 있다는 것도 꽤 매력이네요. 러스트와 다르게 문법이 간단한 것도 좋고. 물론 러스트만큼 안전하진 못하겠지만... 러스트를 쓰면서 느끼는 오버엔지니어링 하는 느낌은 좀 덜 들겠다는 느낌. Go도 역시 비교 대상으로 언급이 되는데, 아무래도 런타임이 없는 zig 쪽이 덜 부담스러운 상황이 있겠죠. 특히 더 저수준으로 내려간다거나, 많은 요청을 처리할 필요는 없는 경우라면 Go 보다는 손이 가는 선택지가 될 수도...
그래서 러스트와 Go 중간에서 잘 포지셔닝 한다면 의외로 괜찮은 선택이 될 수 있겠다는 생각이 듭니다.