Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
이 글은 Rust와 Zig의 개발 경험을 비교하며 오류 처리 방식과 의존성 관리에 대해 논합니다. 특히 Zig는 상위 호출자로 오류를 전파하는 것이 쉽고, 기본 기능들이 잘 갖춰져 있어 프로젝트 시작 및 유지보수가 용이하다고 설명합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기Rust가 프로그래머에게 패닉을 넣도록 유도한다는 설명과 달리, 패닉을 넣는 것이 일반적인 관행은 아님. ?를 쓰기 위해 반드시 박싱된 오류를 반환해야 하는 것도 아니며, 오히려 그런 반환형은 코드의 나쁜 징후로 봄. 의존성을 피하고 싶다면 thiserror를 쓸 때처럼 오류 열거형을 정의하고 Error 트레이트를 직접 구현하면 됨. 충분히 가능하고 그리 번거롭지도 않음.
다만 Zig에서 새 프로젝트를 시작하는 과정은 ADHD가 있는 내게 꽤 힘들 때가 있음. 바로 문제를 만지작거리고 싶은데, 먼저 build.zig에 여러 프로젝트에서 쓰는 비슷한 기능을 연결하게 됨. ZLS를 위한 check 단계나 test 단계 등을 만족스럽게 구성하고 나면, 전혀 흥미롭지 않은 작업에 이미 도파민 예산을 꽤 써버린 느낌임.
시제품을 만들 때는 패닉이 흔함. 오류를 처리하는 가장 쉬운 방법이라서 쓰고, 잊기 쉬워 실제 운영 코드에도 남곤 함. 신규 개발자와 LLM이 배우는 온라인 예제에 이런 코드가 많은 것도 상황을 악화시킴. 자주 쓰는 앱에서 Rust 패닉을 겪었고, 오류 메시지를 출력하려고 expect를 남용하는 것도 봤음. 나도 시제품을 만들 때 그렇게 한 적이 있음.
반면 Zig에서는 오류를 상위 호출자로 전파하는 것이 가장 쉬운 경로임. 나중에 제대로 된 오류 처리를 붙이기도 훨씬 쉽고, 애플리케이션 전체를 중단시키지도 않음. 오류 열거형과 Error를 직접 구현해 본 적도 있지만, Zig보다 훨씬 번거롭고 오류를 조합하는 방식도 그만큼 깔끔하지 않음.
프로젝트 초기 설정이 번거롭다는 점은 이해함. 프로젝트마다 복사해서 쓸 기본 build.zig를 마련해 두는 건 어떨까? 반복 코드에는 복사·붙여넣기가 오래된 해법인데, 프로젝트별 차이 때문에 어려운 부분이 있는지 궁금함. ZLS에 넣을 만한 기능일 수도 있겠음.
방대한 의존성 트리에 지쳐 Rust에서 Zig로 옮겼다고 하는데, Rust에서 의존성을 줄이지 못하는 이유가 궁금함.
글에 답이 있음. 대부분의 의존성이 다시 수많은 의존성을 끌어오고, Rust 표준 라이브러리에 여러 프로젝트가 필요로 하는 필수 기능이 빠져 있음. 큰 의존성 트리 없이 Rust를 쓰는 것은 가능하지만 고통스러운 작업임. 다른 분야에서처럼 Rust 생태계가 이 부분도 개선해 나가길 바람.
Zig는 의존성을 대하는 문화와 함께, 오류 처리나 직렬화 같은 기본 기능을 언어나 표준 라이브러리에 갖춰 두어 두 문제를 모두 피함.
지난 Zig Day Seattle에서 좋은 시간을 보냈다는 두 번째 블로그 글을 보니 반가움. 이런 긍정적인 피드백이 행사를 계속 열게 해줌. 적절한 장소만 찾으면 행사 준비 자체가 어렵지는 않음.
다음 Seattle 행사 전에 Portland에 가보는 것도 가능함. Zig Day Portland being on Novemeber 7th가 11월 7일이고, Zig Day Seattle is the very next day on November 8th는 바로 다음 날인 11월 8일이라 오래 기다릴 필요도 없음.
이 글로 Zig에 관심이 생겼고 Bellevue 도서관에 오기 어렵지 않다면 참여해 주길 바람. 초보자도 대환영이며, 혹시 몰라 이번에는 큰 방을 확보해 둠.