Hacker News 의견들

• 나는 Zig 팬은 아니지만, 작은 팀이 꾸준히 발전하는 모습이 보기 좋음
  완성보다는 실험과 점진적 개선을 중시하는 태도가 인상적임
  1.0을 서둘러 내는 대신 장기적인 목표를 향해 나아가는 게 더 중요하다고 생각함
  한 명 중심의 프로젝트치고는 놀라운 성취이며, 노력하는 사람들에게 정당한 인정이 필요함

  • 나는 새로운 언어를 배울 때마다 TCP/UDP 멀티플레이 서버가 있는 게임 엔진을 만들어보는데, 최근엔 Zig로 시도했음
    지금까지 중 가장 재미있고 생산적인 경험이었음
    Rust의 엄격한 메모리 관리보다 Zig의 단순함이 훨씬 잘 맞음
    인생은 짧고, 나는 그저 빠르고 잘 정리된 소프트웨어를 만들고 싶음

• Zig 관련 글마다 비판이 많지만, 왜 그렇게 신경 쓰는지 모르겠음
  Andrew와 팀이 믿는 바를 실현하려는 엔지니어링 정신이 오히려 영감을 줌
  Zig가 주류가 될지 걱정할 필요 없음, 문제 해결에 도움이 되면 그걸로 충분함
  언어를 정체성처럼 대할 필요는 없음

  • 이런 현상을 없애려면 프로그래머들이 받는 경제적 인센티브를 바꿔야 함
    언어와 라이브러리는 곧 ‘팔 수 있는 기술’이기 때문에, 사람들은 자신이 쓰는 도구의 시장성을 의식함
    게다가 의사결정권자들이 엔지니어를 교체 가능한 자산으로 보는 경향도 문제임
  • 이런 언어 논쟁은 Zig만의 일이 아님
    Lisp, Ruby, Rust 등에서도 반복되어 왔고, 정체성 싸움이 업계의 고질적인 문제임
  • 새로운 언어 스택은 리눅스 배포판에서 유지보수 부담을 늘림
    보안·아키텍처 지원 등 장기 관리가 필요함에도, 개발자들은 그 비용을 간과함
    Zig는 아직 안정적이지 않아 특정 버전에서만 패키지가 컴파일됨
    다른 언어 개선으로도 해결 가능한 문제를 굳이 새 언어로 풀 필요가 있는지 의문임
  • 주류 언어가 되려면 대부분의 사용 사례를 커버할 예측 가능한 라이브러리 생태계가 필요함

• Zig가 1.0이 되기 전까지는 따라가 봐야 의미 없다고 느낌
  지금 구조는 여러 번 다시 짜일 가능성이 높음
  나도 한때 관심 있었지만, 내 생애에 1.0을 볼 수 있을지 모르겠음

  • 실제로 Zig의 호환성 깨짐은 대부분 표준 라이브러리(stdlib)에서 발생함
    파일 입출력 같은 기본 기능은 거의 동일하고, 네임스페이스만 바뀜
    나는 ‘살아 있는 언어’가 더 낫다고 생각함
    1.x 이후에도 stdlib을 슬림하게 유지하기 위해 버전별 인터페이스 관리 전략이 있으면 좋겠음
  • Zig 언어 자체는 좋아하지만 stdlib 품질에 의문이 생김
    I/O 프레임워크를 직접 만들다 보니 테스트 부족과 잘못된 어셈블리 코드를 발견했음
    여러 번 지적했지만 수정되지 않아 신뢰가 떨어짐
  • 대규모 프로젝트에는 망설여질 수 있지만, Zig는 이미 비즈니스적으로 가치 있음
    특히 클라우드 환경에서 성능 최적화로 서버 비용을 90% 이상 절감할 수 있음
    Python이나 Node로는 한계가 있어 결국 C, C++, Rust, Zig 중 하나로 내려가야 함
    그중 Zig는 배우기 쉽고, 읽기·테스트하기 편함
  • 참고로 Bun도 Zig로 작성되어 있음
    이미 실무 수준에서 쓰이고 있는 언어임
  • 우리 팀(ZML)은 std.Io 도입 이후 Zig master 브랜치를 계속 따라가고 있음
    대부분의 변경이 실제로 언어 개선으로 느껴짐

• Rust의 io_uring 지원이 아직 완성되지 않은 상황에서 Zig가 먼저 구현을 시도하는 게 흥미로움
  Rust에서는 안전하고 제로코스트인 추상화를 설계하기가 어려움

• 이번 소식은 아직 미완성 구현에 대한 것임
  예를 들어 GCD 버전에는 네트워킹이 없음
  인터페이스가 점점 커지고 있어 완성형이라기보다 현재 스냅샷에 가까움

  • 하지만 글의 서두에서 이미 실험적 단계임을 명시했고,
    앞으로 해야 할 6가지 주요 과제를 구체적으로 나열했음

• 스택 메모리 최적화 관련 이슈가 있음
  서로 다른 블록에서 [500]u8을 사용해도 스택 프레임에 500바이트만 차지하도록 하는 기능이 필요함
  이는 그린 스레드 코루틴 스택과 관련해 특히 중요함

• 나는 Zig의 지속적인 개선 노력을 긍정적으로 봄
  현재 io_uring을 제대로 다루는 언어는 없음
  Zig가 이 부분을 잘 해결하면 큰 우위를 점할 것임
  안정성보다 학습과 실험을 중시하는 태도가 더 가치 있다고 생각함

  • 저수준 언어에서까지 async를 원한다는 게 흥미로움
    나는 Zig에서 libxev를 사용해 io_uring을 직접 제어하는 방식을 선호함
  • 나도 긍정적이지만, Zig가 C처럼 장기 안정 버전(LTS) 을 내놓을 시점이 궁금함
    C의 성공 요인은 안정성과 일관된 개발 문화였음

• Zig가 freestanding 타깃을 진지하게 다루는 점이 좋음
  0.16 버전에서 코드 재사용성이 더 높아질 것으로 기대함

• macOS 내부를 오랜만에 살펴봤는데, GCD를 유지한 게 반가움
  병렬화의 균형 잡힌 접근이라 생각함

• 다른 언어들이 논쟁만 하는 동안 Zig는 직접 시도하고, 필요하면 되돌림
  실전에서 검증된 API가 최고의 설계라고 믿음
  구버전을 유지할 수도 있고, 최신 버전으로 가면 더 깔끔하고 빠른 도구를 얻을 수 있음

  • Jai는 게임 개발 중심이라 범용성이나 안전성 측면에서 부족함
    C++처럼 복잡하지만 Zig는 C 수준의 단순함을 유지함
    Carbon은 아직 실체가 없는 상태임
  • Zig가 1.0이 아니라고 비판하는 건 이상함
    Jai는 11년째 클로즈드 베타인데, Zig는 이미 여러 실제 프로젝트에서 사용 중임
  • 언어는 20년이 걸리더라도 제대로 완성되는 게 낫다고 생각함
    Python 2→3, Rust async, Go 제네릭, C++ 등에서 본 무분별한 변화가 오히려 해로움