디버그 모드에서 자체 호스팅 x86 백엔드가 기본값으로 설정됨

(ziglang.org)

1P by GN⁺ 3일전 | ★ favorite | 댓글 1개

이제 x86_64 타겟 시, Zig의 자체 x86 백엔드가 디버그 모드에서 기본값으로 적용됨
기존 LLVM 기반보다 더 많은 동작 테스트 통과와 빠른 컴파일 속도 달성함
자체 백엔드 도입으로 Zig의 컴파일 시간 대폭 단축 및 일부 작업의 효율성 증대됨
최근 보완된 빌드 시스템, BSD 계열 OS 지원 확대, UBSan 런타임 개선 등 여러 기능 강화 진행됨
표준 라이브러리와 자체 도구 최적화로 Zig만의 경쟁력 강조됨

결론

Zig는 자체 기반의 성능 향상, 빌드 효율, 디버깅 편의성 강화를 핵심 목표로 혁신적 변화를 계속 추진함
독립적 알고리듬, 컴파일러, 빌드/런타임 도구 모두에서 차별화된 경쟁력을 확보하는 중임
BSD 등 다양한 플랫폼 지원, 사용자 중심 메시지 개선, 메모리 모델 혁신을 포함하여 소프트웨어 엔지니어 실무자에게 실질적으로 유익한 발전을 이어가고 있음

▲

GN⁺ 3일전 [-]

Hacker News 의견

내가 알기로 Zig는 개발 환경을 더 좋게 만들기 위해 매일 다양한 기능을 작업 중인 상황임. 예를 들어 최근에는 이 PR도 있었음. 예전에 Zig에서 핫 코드 스와핑(hot code swapping)도 개발 계획에 있었고, 이 개발 속도라면 아마도 1년 내에 x86_64에서 이 기능이 가능해질 거라는 예상임. 개인적으로 느끼는 가장 큰 불편함은 comptime의 속도임. 컴파일 타임에 brainF** DSL을 돌렸던 실험이 있었는데, 정말 느리게 돌아감(하지만 재밌는 실험이었음). 컴파일러의 이 부분이 언제쯤 개선될지 궁금함. 새로운 백엔드들에 대해서도 굉장히 기대 중이며, Zig용 나만의 URCL 백엔드도 만들어 보고 싶은 마음임 😉
- comptime 성능 개선에 대해선 뭘 해야할지 이미 알고 있고, 아주 예전에 관련 브랜치도 시작했던 경험이 있음. 하지만 이건 의미있는 규모로 시맨틱 분석 코드를 다시 작업해야 하는 부분이라, 중요한 일 중 하나지만 다른 우선순위들과 경쟁하는 상황임
- 핫 코드 스와핑은 게임개발 분야에서 엄청난 변화를 줄 수 있는 기능임. Zig에서 이게 기본적으로 컴파일러 플래그만으로 지원될 예정이라는 점이 놀랍게 다가옴. clang으로는 시도조차 힘든 것이기 때문임
- URCL에 대해 깊게 살펴보진 않았지만, 이게 나를 또 다른 토끼굴로 이끌고 있음. 마인크래프트용으로 만들어진 IR이 언어의 실제 컴파일 대상이 되는 진짜 기괴한 시나리오가 만들어지는 게 아닐지 상상하게 됨
- 커스텀 백엔드를 만드는 게 쉬운지 궁금함. 아직 직접 시도해보진 않았지만, AIR를 받아서 메모리 안전성 리포트를 만들어주는 백엔드 실험을 해보고 싶은 생각임(예를 들면, 정의되지 않은 값 사용, 스택 포인터 이스케이프, use-after-free, double free, alias xor mut 등 체크하는 방식)
- comptime이 정말 느린 게 문제인지 궁금증이 있음. 나는 JSON-RPC 라이브러리 제작 중인데, 컴파일 타임에 comptime을 적극적으로 활용해서 JSON을 임의 함수로 분배하고 있음. Zig의 강력한 정적 타입으로 런타임에 임의 파라미터가 있는 함수에 동적으로 분배하는 게 불가능해서, 컴파일 타임에 함수 타입 맵핑을 만들어내는 방식을 써야만 했음. 이러면 각 함수마다 comptimed된 코드가 복사되면서 바이너리 크기는 커질 수밖에 없다는 점이 걱정임
이미 이 정도까지 도달한 것만으로도 대단한 성과임. devlog에서도 밝혔듯 앞으로가 더 기대되는 상황임. 컴파일러가 빌드할 때 바이너리의 필요한 부분만 바꾸는 개념은 신선하면서도 파격적으로 느껴지며, Zig 프로젝트 덕분에 이제 실현 가능한 목표가 됨. 앞으로 굉장히 흥미로운 시간임
Zig 컴파일러와 같은 대형 프로젝트에서는 빌드 시간이 75초에서 20초로 줄었다는 언급이 있음.
앞으로 이걸 어디까지 개선할 수 있을지 무척 궁금함. Zig 개발자는 굉장히 똑똑한 것 같다는 느낌임.
패키지 매니지먼트는 어떤 형태인지 궁금함. 예전에 QuickJS + SDL3 앱을 Zig로 해보려 했지만, C++의 복잡함에 밀려 결국 Rust로 갔었음. Zig에서도 시도해보고 싶음
- Zig의 패키지 매니지먼트는 Rust에 비해 좀 더 수동적임. CLI에서 패키지 URL을 직접 가져오고, 빌드 스크립트에서 모듈을 임포트하는 방식임. 이 방식의 장점은 임의 아카이브도 쉽게 의존 패키지로 쓸 수 있고, 많은 Zig용 C 라이브러리 패키지는 단순히 언터치드(tarball) 릴리스를 빌드 스크립트에서 직접 연결하는 구조임. 다만, 초보자에겐 조금 복잡할 수 있음
  SDL3의 경우 네이티브 Zig 래퍼(https://github.com/Gota7/zig-sdl3)와, 좀 더 단순하게 C 라이브러리/ API를 Zig화한 https://github.com/castholm/SDL 두 가지가 있음
  QuickJS는 오직 C API(https://github.com/allyourcodebase/quickjs-ng)만 지원함
  Zig는 C 패키지를 직접 사용하기가 매우 쉽지만, 타입이 엄격해 API를 다룰 때 타입 캐스팅이 자주 필요할 수 있음
- dmd D 컴파일러는 자체를 디버그 빌드 기준 약 18.4초에 컴파일할 수 있음.
  내 프로세서는 아주 오래된 AMD Athlon 64 X2(4400+)인데 워낙 빠르게 돌아가서 아직 업그레이드조차 안 했음
  (자세한 CPU 정보 목록 포함)
- fast development cycle을 위해 Zig를 20초만에 빌드하는 가이드가 있는지 궁금증임. 예전에 Zig를 빌드할 때 여러 스테이지(특히 WASM에서 부트스트랩)가 있어 시간이 정말 오래 걸렸던 경험이 있음
- Zig가 LLVM을 쓴 상태로도 자체를 75초만에 컴파일한다는 점이 엄청 놀라움
Zig에 무리한 요구를 전혀 할 의도는 없고, 오픈소스임을 잘 알고 있지만 현실적인 1.0 출시 일정에 가장 많은 관심이 있음.
Zig는 저수준 언어에서 내가 원하던 바를 거의 완벽히 담은 언어이고, 이제 안정화만 기다리는 중임.
그리고 Zig의 미니멀리즘 디자인 철학에 진심으로 감탄함
- tigerbeetle과 같은 실제 프로젝트들은 보통 릴리스 버전을 고정해서 사용하고 nightly는 실험용으로만 쓰는 경우가 많은 것으로 알고 있음
완전 초보자로서 Zig가 다른 언어 대비 가지는 장점은 무엇인지 궁금증임. 더 현대적인 C로 이해하고 있는데, 무엇이 ‘현대적’인 부분인지 궁금함
- 당장 떠오르는 장점 몇 가지 정리임
  - 여러 개 별도 도구와 언어를 합치지 않아도 되는 통합 빌드 시스템
  - C의 배열(버퍼 오버플로우 문제) 대신 길이를 명확히 아는 슬라이스 제공
  - null 포인터가 기본적으로 허용되지 않는 명확한 optional 타입(필요시엔 타입이 명시적으로 드러남)
  - enum, tagged union, 그리고 switch 문 exhaustive 체크 강제
  - 에러 처리가 명확(kinda Rust 스타일). 함수가 반드시 에러를 반환하면, 호출자가 무시 불가. C처럼 반환값 무시해도 넘어가는 구조가 아님. 다만, 에러와 데이터를 한 번에 반환하는 표준문법이 없다는 점은 아쉬움
  - "defer", "errdefer" 블록으로 함수 반환/에러 발생시 자동 정리 작업 구현
  - 매크로 대신 comptime 코드 생성, 타입 리플렉션(@typeInfo 등)
  - 메모리 할당자는 호출자가 직접 관리(메모리 위치와 방식에 더 많은 결정권)
  - GeneralPurposeAllocator를 사용하면(초보 기준) 메모리 누수 추적이 좀 더 쉬움
    C와 친숙하지 않고, C의 여러 불합리하고 직관적이지 않은 점 때문에 저수준 프로그래밍에 항상 진입장벽을 느꼈는데, Zig는 처음으로 시스템 프로그래밍에 재미와 흥미를 느끼게 해준 언어임
Zig를 20초만에 빌드할 수 있는 가이드가 있는지 궁금함. 개발 주기를 빠르게 돌리고 싶은데, stage1/2/3 모두 빌드에 시간이 오래 걸려 기여하기가 쉽지 않았던 경험이 있음
Zig에서 zig init으로 헬로월드 빌드시 9.3MB가 나온다는 점이 있다면, -Doptimize=ReleaseSmall 플래그를 쓰면 7.6KB로 줄어듦
플래그 하나로 1000배 이상 차이가 나는 상황임
- 실제로 그 차이의 82%는 디버그 정보 때문임
  -OReleaseSmall -fno-strip은 580KB, -ODebug -fstrip은 1.4MB까지도 나옴
  Zig의 x86 백엔드로 Zig 전용 LLDB fork로 훨씬 더 나은 디버깅 경험을 제공함
  현재 comptime 로직을 디버깅 중에 스텝으로 볼 수 있는지는 잘 기억나지 않지만 최근 논의 주제였음
Julia가 성능 이점 확보를 위해 Zig를 컴파일러로 고려해볼 만하다는 생각임. 매 릴리즈마다 성능 저하 걱정으로 불안해하는 Julia 개발자들의 마음도 기억남
- Julia는 사실상 LLVM에 강하게 묶여 있음. 생태계의 여러 부분이 LLVM intrinsics, autodiff(Enzyme), GPU 컴파일 등의 존재에 의존함.
  컴파일러는 꽤 리타겟이 가능해지는 중인데, 이 부분도 현재 활발히 연구되고 있음.
  미래에는 Zig가 언어 일부의 대안 컴파일러가 되는 그림도 상상해볼 수 있음
- LLVM 자체가 Julia의 public API라는 의견이 있음. 실제로 @code_llvm같이 직접 IR을 보여주는 매크로도 있음
- 컴파일 타임을 줄이는 데에는 분명 효과가 있겠지만, 아직 Julia 쪽에서도 작업할 것이 많음
  컴파일 캐시를 더 세분화하거나, i invalidation 방지용 툴링, world splitting 최적화 제거, 컴파일러의 멀티스레딩 활용 증가, 특정 시그니처에 대해 자동 사전컴파일, lazily code를 컴파일/핫스왑하는 기능 등이 있음
Zig에게는 엄청난 발전이고, Rust와 비교할 때 앞으로의 주된 차별화 요소가 될 방향이라 생각함. 참고로, 퍼포먼스 분석 툴의 렌더링 코드 대부분을 내가 직접 짰는데, 내 코드가 온라인에서 널리 사용되어 기쁨
poop 프로젝트 링크
- Rust에도 cranelift를 활용하는 유사한 시도가 있음
  rustc_codegen_cranelift 참고
이게 바로 Zig에서 async/await 기능을 다시 들여오기 위한 전제조건 중 하나라는 생각임
async에 대한 Zig의 공식 FAQ도 참고할 만함
- 이 부분은 이미 다 정리한 상태이고, 앞으로 2-3개월 내에 흥미로운 업데이트를 공개할 수 있을 것임. 거의 표준 라이브러리를 새로 만들 듯 I/O 전체를 다시 작업하고 있음
- 링크에 따르면, async는 아예 다시 돌아오지 않거나 최소 2028년까지는 꿈도 못 꾸는 상황으로 보임

답변달기

디버그 모드에서 자체 호스팅 x86 백엔드가 기본값으로 설정됨

최신 주요 소식 요약

2025년 6월 8일 – 자체 호스팅 x86 백엔드, 디버그 모드에서 기본값으로 전환

2025년 6월 6일 – 빌드 시스템 소개 영상

2025년 5월 20일 – FreeBSD 및 NetBSD 타겟 지원 강화

2025년 4월 9일 – 공식 Zig 사이트, 독립 실행형 Zine으로 빌드

릴리즈 및 기능 개선 소식

2025년 2월 7일 – 디버그 할당기 및 SmpAllocator 혁신

2025년 1월 24일 – Zig 전용 디버깅 환경 제공

결론

Hacker News 의견