이 글은 처음엔 “Zig은 단순한 언어가 아니라 완전히 새로운 프로그래밍 방식”이라고 주장하지만, 실제로는 Zig만의 고유한 기능을 거의 다루지 않음
타입 추론, 익명 구조체, labeled break 등은 이미 오래전부터 다른 언어들에 존재했음
진짜 독특한 건 comptime인데, 이 부분은 전혀 언급되지 않음
Lisp 매크로처럼 완전히 새로운 개념은 아니지만, Zig이 이를 제네릭 대신 사용하는 방식은 흥미로움
하지만 글의 주장은 과장된 느낌이 강함
Rust도 마찬가지로 “완전히 새로운 방식”이라 할 수 있음
Rust는 코드 실행 시점을 명확히 표현할 수 있고, 전체 코드 공간을 탐색하는 쿼리 엔진 같은 설계가 인상적임
D 언어는 이미 2007년부터 컴파일 타임 함수 실행을 지원했음 D 문서 링크 참고
const-expression이면 자동으로 실행됨
C/C++을 하나로 묶는 건 이제 의미가 없음
Java/Scala처럼 완전히 다른 언어이기 때문임
comptime은 마법적인 발명이라기보다 메타프로그래밍의 현대적 버전임
Zig은 C++ 템플릿보다 깔끔하지만, 혁명적이라기보단 실용적인 대안 정도로 느껴짐
개인적으로는 Rust 때처럼 과도한 열광이 이해되지 않음
“완전히 새로운 방식”이라는 문구를 보고 LISP이나 Prolog 같은 새로운 패러다임을 기대했는데, 실제로는 그런 게 없었음
Zig 문서를 다 읽었는데도 놀랄만한 게 없어서 당황했음
Zig의 가장 큰 문제는 에러에 데이터를 붙일 수 없다는 점임
에러는 부가 채널로만 전달돼서 디버깅이 어렵고, 결국 개발자들이 에러 데이터를 생략하게 됨 관련 이슈 참고
AccessDenied 같은 단순 코드만으로는 원인을 알기 힘듦
matklad의 글을 읽었는데, 에러 코드와 진단 정보를 분리하는 접근이 설득력 있었음
실제로 복잡한 Error 객체를 써도 별도의 진단 채널이 필요할 때가 많음
시스템 언어에서는 에러에 데이터를 붙이는 게 항상 좋은 건 아님 성능 오버헤드나 시스템 상태 문제 때문에, 상황에 따라 지연 바인딩으로 처리하는 게 더 안전함
Zig은 이런 정밀성과 결정성을 우선시하는 철학을 가짐
Zig에서도 에러 스택 트레이스에 사용자 정의 정보를 넣는 기능이 논의 중임 관련 이슈 참고
하지만 진짜 필요한 건 구조적 로깅과 호출 스택 기반의 문맥 추적 기능임
std.zon이 좋은 예시로 꼽히며, 커뮤니티에서 다양한 에러 처리 패턴을 모아 표준에 반영하려는 움직임이 있음
에러에 데이터를 못 붙이게 하는 건 오히려 명확한 에러 설계를 유도함
게으른 개발자가 무조건 데이터를 덕지덕지 붙이는 걸 막을 수 있음
“Zig 개발 방식 자체가 새로운 언어 개발 방식”이라는 주장에 공감함
기능을 신중히 검토하고 불필요한 걸 제거하는 느린 진화 과정이 인상적임
하지만 이런 접근은 Java나 Rust 등에서도 흔함
Zig만의 독특한 점이 무엇인지 더 구체적으로 듣고 싶음
Zig을 PyPI로 설치할 수 있는 게 마음에 듦 ziglang 패키지를 pip install ziglang으로 설치하면 바로 사용 가능함 uvx를 이용해 C 코드를 빌드할 수도 있음
Python wheel로 임의의 소프트웨어를 번들링할 수 있어서 이런 설치 방식이 가능함
하지만 이런 접근은 nix보다 불편한 재발명처럼 느껴짐
Nim에도 이런 설치 옵션이 있었으면 좋겠음
개인적으로는 pip/uv보다 micromamba나 pixi가 더 나은 패키지 관리 방식이라 생각함
AI 도구 덕분에 이제는 어떤 언어든 배우기가 훨씬 쉬워졌음
Ada, Object Pascal, Modula-2 같은 언어에서도 이미 존재하던 기능들을 Zig의 “혁신”으로 포장한 점이 아쉬움 C 스타일 문법으로 다시 포장되니 40년 전 아이디어가 새로워 보이는 현상이 흥미로움
글의 도입부는 좋았지만, 이후엔 단순히 Zig 기능 나열로 끝남
Zig의 직관적 문법과 명시적 제어 흐름(defer 등)은 매력적임
comptime 덕분에 별도의 매크로 문법을 배울 필요도 없음
Zig의 진짜 매력은 불필요한 중복이 없는 설계임
모든 구성요소가 자연스럽게 맞물려서, 처음 써도 오래 써온 도구처럼 느껴짐
Hacker News 의견
이 글은 처음엔 “Zig은 단순한 언어가 아니라 완전히 새로운 프로그래밍 방식”이라고 주장하지만, 실제로는 Zig만의 고유한 기능을 거의 다루지 않음
타입 추론, 익명 구조체, labeled break 등은 이미 오래전부터 다른 언어들에 존재했음
진짜 독특한 건 comptime인데, 이 부분은 전혀 언급되지 않음
Lisp 매크로처럼 완전히 새로운 개념은 아니지만, Zig이 이를 제네릭 대신 사용하는 방식은 흥미로움
하지만 글의 주장은 과장된 느낌이 강함
Rust는 코드 실행 시점을 명확히 표현할 수 있고, 전체 코드 공간을 탐색하는 쿼리 엔진 같은 설계가 인상적임
D 문서 링크 참고
const-expression이면 자동으로 실행됨
Java/Scala처럼 완전히 다른 언어이기 때문임
Zig은 C++ 템플릿보다 깔끔하지만, 혁명적이라기보단 실용적인 대안 정도로 느껴짐
개인적으로는 Rust 때처럼 과도한 열광이 이해되지 않음
Zig 문서를 다 읽었는데도 놀랄만한 게 없어서 당황했음
Zig의 가장 큰 문제는 에러에 데이터를 붙일 수 없다는 점임
에러는 부가 채널로만 전달돼서 디버깅이 어렵고, 결국 개발자들이 에러 데이터를 생략하게 됨
관련 이슈 참고
AccessDenied 같은 단순 코드만으로는 원인을 알기 힘듦
실제로 복잡한
Error객체를 써도 별도의 진단 채널이 필요할 때가 많음성능 오버헤드나 시스템 상태 문제 때문에, 상황에 따라 지연 바인딩으로 처리하는 게 더 안전함
Zig은 이런 정밀성과 결정성을 우선시하는 철학을 가짐
관련 이슈 참고
하지만 진짜 필요한 건 구조적 로깅과 호출 스택 기반의 문맥 추적 기능임
게으른 개발자가 무조건 데이터를 덕지덕지 붙이는 걸 막을 수 있음
“Zig 개발 방식 자체가 새로운 언어 개발 방식”이라는 주장에 공감함
기능을 신중히 검토하고 불필요한 걸 제거하는 느린 진화 과정이 인상적임
Zig만의 독특한 점이 무엇인지 더 구체적으로 듣고 싶음
Zig을 PyPI로 설치할 수 있는 게 마음에 듦
ziglang 패키지를
pip install ziglang으로 설치하면 바로 사용 가능함uvx를 이용해 C 코드를 빌드할 수도 있음Ada, Object Pascal, Modula-2 같은 언어에서도 이미 존재하던 기능들을 Zig의 “혁신”으로 포장한 점이 아쉬움
C 스타일 문법으로 다시 포장되니 40년 전 아이디어가 새로워 보이는 현상이 흥미로움
글의 도입부는 좋았지만, 이후엔 단순히 Zig 기능 나열로 끝남
Zig의 직관적 문법과 명시적 제어 흐름(defer 등)은 매력적임
comptime 덕분에 별도의 매크로 문법을 배울 필요도 없음
모든 구성요소가 자연스럽게 맞물려서, 처음 써도 오래 써온 도구처럼 느껴짐
Zig의
for (0..9)구문은 직관적이지만, 열린 구간이라 종종 헷갈림Python의 range(0, 9)처럼 마지막 값 포함 여부를 잊기 쉬움
0..9와0..=9로 구분해서 명확함구간 크기가 단순히 차이로 계산되고, 역방향 순회도 간단해짐
0..<5(열린)과0...5(닫힌)으로 더 명시적으로 구분함Zig의 식별자 규칙이 마음에 들지 않음
snake_case와 camelCase가 섞여 있어서 어색함
그래도 빌드 시스템, 메모리 할당자, 컴파일 경험 등은 훌륭함
Rust를 주로 쓰지만 Zig에 대한 호기심은 계속 있음
C 라이브러리의 접두사 규칙도 마찬가지로 귀찮음
Zig의 매력은 어떤 한 기능이 아니라, 실용적인 결정들의 누적임
처음엔 급진적으로 보이던 선택들도, 이해가 깊어질수록 납득하게 됨
Zig은 호기심 많은 개발자에게 보상해주는 언어임
Zig이 좋은 이유 중 하나는 저수준 시스템 코드의 현실을 인정한다는 점임
많은 언어들이 미학적 이유로 이런 부분을 외면하지만, Zig은 그렇지 않음
page_allocator 문서 참고