미첼 하시모토, Zig 소프트웨어 재단에 30만 달러 기부 약정

 (mitchellh.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Mitchell Hashimoto 부부가 Zig Software Foundation에 30만 달러를 약정해, Zig의 독립적 개발과 재단 운영을 공개적으로 지원함
  • 기부금은 2년에 걸쳐 연 15만 달러씩 지급되며, 첫 번째 분할금은 이미 전달됨
  • Hashimoto는 2019년부터 Zig를 지켜보다가 2021년 사용을 시작했고, 2022년부터 글 작성과 컴파일러 기여를 이어옴
  • 2023년에 공개한 터미널 프로젝트 Ghostty도 Zig로 작성됐으며, 현재 그의 코딩 시간 대부분이 Zig에 쓰이고 있음
  • Zig는 아직 안정성과 더 넓은 산업 채택까지 갈 길이 남아 있지만, Hashimoto는 강한 커뮤니티와 지속 가능한 자금 모델을 갖춘 프로젝트로 보고 기부를 권함

30만 달러 기부 약정

  • Mitchell Hashimoto와 그의 아내는 Zig Software Foundation에 30만 달러를 기부하기로 약정함
  • 지급은 2년에 걸쳐 매년 15만 달러씩 이뤄지는 구조임
    • 첫 번째 분할금은 이미 전달됨
  • ZSF는 별도의 공지에서 재단의 사명과 구체적인 자금 사용처를 다룸

Hashimoto가 Zig를 지원하는 이유

  • Hashimoto는 2019년 무렵부터 Zig 프로젝트를 지켜봤고, 2021년에 프로젝트에 대한 기대감을 공개적으로 공유함
  • 2021년 후반부터 Zig를 사용하기 시작했으며, 2022년 초부터 Zig 관련 글을 쓰고 컴파일러에 기여하기 시작함
  • 이후에도 Zig 저장소에 수십 건의 코드 기여를 이어옴
  • 2023년에 공개한 터미널 프로젝트 Ghostty는 Zig로 작성됐고, 현재 Hashimoto는 대부분의 코딩 시간을 Zig에 쓰고 있음

Zig와 ZSF에 대한 평가

  • Hashimoto는 Zig를 변화와 영향력을 만들 수 있는 독립 소프트웨어 프로젝트로 보고 있음
  • Zig는 열정 프로젝트로 시작했고 지금도 그런 성격을 유지하며, 프로젝트 운영과 커뮤니티가 강하다고 평가함
  • 자금 모델은 투명하고 지속 가능하며, 기술적으로는 야심 있고 혁신적이면서도 실용적이고 현실적이라고 봄
  • 안정성과 더 넓은 산업 채택까지는 아직 시간이 필요하지만, 도달할 경로와 기회가 분명하다고 판단함
  • ZSF 자금의 약 3분의 1은 개인 기부에서 나오며, 가능한 사람들에게 기부를 권함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • “우리의 자선 활동은 보통 비공개지만, 제 배경상 Zig에 대한 공개 지지가 프로젝트에 실제 도움이 될 수 있다고 생각해 예외로 한다”는 문장이 묘하게 와닿았음
    정확히 표현하긴 어렵지만, 그 안에 있는 기본적인 품위는 칭찬받을 만함

    • 나도 비슷하게 느꼈지만, 어쩌면 반대 방향이었음
      다른 자선 활동은 공개 지지가 도움이 되지 않는다는 뜻인가? 그렇다면 그 활동들은 어떤 성격인 건지 궁금했음. 물론 자기 돈으로 하는 자선은 결국 마음대로 해도 되지만, 표현은 좀 묘하게 들렸음
    • 돈을 기부하면서 자기 이름을 붙이는 것 자체가 가치가 있다면 충분히 말이 됨
      이 경우에는 그 공개 지지가 본인 기부액보다 더 큰 추가 기여를 끌어낼 수도 있음
    • 믿는 대상을 지원한다고 간단히 밝히고, 왜 신경 쓰는지 설명하는 건 완전히 자연스럽다고 봄
    • 공개 지지라서 그런 건지, 아니면 자선 활동이 보통 비공개라서 그런 건지 궁금함

  • Zig Foundation 관계자가 보고 있다면 구인 게시판을 만드는 걸 강력히 추천함
    특정 분야 독자가 있는 곳에서는 거의 공짜 수익원에 가까움

    • 내가 해보겠음

  • 어리석은 질문일 수 있지만, 웹 개발자라 시스템/저수준 프로그래밍은 보통 호기심으로만 접함
    가능한 경우에는 모두 메모리 안전 언어로 옮기라고들 하는데, Zig에는 그런 보장이 없어 보임. Zig가 새 언어라면 주 용도는 새 프로젝트일 텐데, 그렇다면 메모리 안전 언어로 시작해야 하는 것 아닌가 싶음. Zig의 장점이 “C보다 현대적이고 Rust보다 단순함”이라면 매력은 이해하지만, 메모리 안전성이 부족하면 그 장점이 약해지는 것 아닌가?

    • 메모리 안전성은 유용한 개념이지만 만병통치약도 아니고 이분법도 아님
      최종 목표가 안전성뿐이라면 JavaScript도 충분했을 것임. 안전한 Rust는 메모리 안전을 보장하므로 시스템 프로그래밍에서 큰 개선이지만, 항상 최종 해답은 아님. 애플리케이션에 따라 절충이 있고, 개인적으로는 보장된 안전성보다 안전성을 쉽게 달성할 수 있는지가 더 중요하다고 봄. C와 C++의 문제는 안전하게 만들기가 너무 어려웠다는 데 있음
    • Zig가 진짜 빛나는 영역에서는 Rust로 같은 코드를 쓰면 unsafe가 많이 들어가서, 사실상 메모리 안전 기능을 끄는 셈이 될 가능성이 큼
      실제로 Zig가 Rust보다 덜 안전한지는 아직 더 봐야 함. 어느 쪽이든 프로그램을 안전하게 만들려면 테스트를 많이 써야 하고, Rust가 모든 버그를 마법처럼 없애주지는 않음. Zig에서도 디버그 모드로 충분히 테스트하면 대부분의 메모리 안전 버그를 잡을 수 있을 것임. 그래도 웹 브라우저 같은 걸 만든다면 Rust를 쓸 것 같음
    • C/C++로도 매우 빠르고 매우 안전한 코드를 쓸 수 있음
      게임 업계나, 소프트웨어를 디스크에 구워 배포해야 하던 시절의 산업 전반을 보면 됨. 지금의 문제는 언어 복잡도가 커졌고, 소프트웨어 개발자의 평균 숙련도가 떨어졌다는 데 있음. Google이 Go를 만든 것도 어느 정도 이 문제를 풀기 위해서였고, Rust는 메모리 안전성을 설계 핵심에 둔 또 다른 언어임. Rust가 더 안전한 프로그램 작성에 유리한 또 다른 이유는 C++보다 훨씬 덜 복잡하다는 점임. 점점 복잡해지고는 있지만, 다행히 Rust 커뮤니티에는 메모리 안전성 개념이 깊게 자리 잡아서 언어가 복잡해져도 그 장점과 개발자들의 습관은 계속 남을 것임
      Zig도 안전성을 중시한다면 좋은 선택임. defer 같은 문법으로 단순화하고, 개발 중 메모리 안전 문제를 잡도록 여러 실행 대상과 도구를 제공함. 컴파일러가 강제하는 건 아니고 개발/비-ReleaseFast 빌드에서 런타임으로 잡는 방식이지만, 그래도 C/C++보다는 개선된 형태임
    • Zig 전체를 “메모리 불안전”하다고 낙인찍는 건 잘 모르겠음
      C에는 없는 메모리 안전 도구와 검사가 꽤 풍부하게 있음. 안전성은 스펙트럼임. C는 C++보다 덜 안전하고, C++는 Zig보다 덜 안전하고, Zig는 Rust보다 덜 안전하고, Rust는 Java보다 덜 안전하고, Java는 Python보다 덜 안전함. 정의되지 않은 동작과 메모리 손상은 모두에서 여전히 가능하고, 얼마나 쉽게 일어나느냐의 차이임
    • 메모리 안전성 부족이 Zig의 장점을 부분적으로 약화한다고 봄
      다만 Zig는 아직 완성된 언어가 아니니 지금 단정하긴 어려움. Zig에도 좋은 메모리 안전 기능은 있고, JavaScript나 Rust 수준은 아니지만 C와 같지도 않음. 예전에 확인했을 때는 해제 후 사용이 큰 문제였고, 이걸 해결하지 못하면 Zig의 미래는 없다고 봄
      JavaScript는 진짜 메모리 안전 언어지만, 런타임과 추상화 수준이 시스템 프로그래밍에는 맞지 않음. 시스템 프로그래밍에는 기본적으로 메모리 안전하되 탈출구가 있고, 컴파일러와 CPU가 대체로 목표로 삼아 온 가상 PDP-11보다 한 단계 위 정도의 낮은 추상화가 필요하다고 봄. 프로그래머가 CPU 실행 모델에 맞춰 생각하되 세부사항에는 묻히지 않게 해주고, C와의 상호 운용도 아주 좋아야 함
      Rust는 첫 번째는 잘 해냈다고 봄. 약점은 두 번째임. 낮은 수준의 기능은 있지만 언어 기능 복잡성의 더미 밑에 묻혀 있음. 또 완전히 안전한 메모리 관리 패턴 일부를 허용하지 않아서 unsafe를 너무 자주 쓰거나, 문제 영역이 아니라 해법 영역에 맞춰 코드를 비틀어야 함
      Zig는 첫 번째가 약함. 좋은 기능도 있지만 큰 빈틈도 있음. 반면 두 번째는 꽤 강함. 바라는 방향은 Zig가 기본 메모리 안전성을 제공하되 Rust보다 훨씬 유연하게 제공하고, 낮은 추상화와 C 상호 운용 측면의 장점을 유지하는 것임

  • 최근 자체 호스팅으로 전환했다는 소식을 보고, 기부금을 낭비하지 않을 특히 효율적인 프로젝트라는 느낌이 들었음

  • “여보, 내가 정말 좋아하는 프로그래밍 언어가 있는데 얘기 좀 하고 싶어”
    “응?…”
    “그 언어가 정말 정말 좋아서 기부를 좀 하고 싶어…”
    “……또 시작이네……”

    • 아니면 이렇게 될 수도 있음
      “좋네! 우리 Cirrus SF50 Vision 타고 Andrew Kelley한테 직접 전달하러 가자”

  • 분명 좋은 소식이지만, 관점을 잡자면 이 금액은 컴파일러를 다루는 숙련 개발자의 연봉 0.75~1명분 정도임
    추측이지만 Microsoft는 TypeScript에만 매년 그 10~20배는 쓰고, C++/C# 등에는 훨씬 더 많이 쓸 것 같음

    • 그만큼 버는 개발자도 있고, Microsoft나 Mozilla 같은 곳에서는 가능성이 더 높지만, 전 세계 시장과 작은 컴파일러 프로젝트까지 보면 연 15만 달러보다 적게 버는 숙련 컴파일러 개발자도 많이 있을 것임
      물론 개발자 비용은 급여만으로 끝나지 않음. 다만 대형 기술 기업에서 ANSI 표준 컴파일러를 다루는 컴파일러 개발자와 비슷한 일자리는, 더 자유로운 일에 비해 실제 업무가 꽤 불쾌해서 위험수당 성격이 많이 섞여 있다고 느꼈음
    • 이런 비교적 새로운 고잠재력 프로젝트의 역할은, 이미 Zig에 확신이 있는 사람에게는 꽤 매력적인 기회일 수 있음
      적절한 자금이 있으면 투잡을 뛰거나 밤/주말에만 일하지 않아도 되게 해주는 촉매가 됨

  • 솔직히 Zig가 매우 기대됨
    군더더기 없이 날렵하고, 실제 사용성을 신경 쓰지 않는 상아탑 사람이 만든 언어가 아님. Haskell처럼 박사들로 이뤄진 팀이 설계한 것도 아니면서, Rust나 Haskell 등의 유용한 아이디어에서는 분명 영감을 받은 것으로 보임. Zig로 코드를 쓰는 일이 꽤 흥미로울 것 같음

    • 나도 Zig가 비슷하게 기대됨
      메모리 안전 보장이 Rust만큼 포괄적이지는 않을 수 있지만, 언젠가 Linux Kernel에서 Zig를 볼 수 있으면 좋겠음. 오래된 커널 C 프로그래머들은 Rust보다 Zig에 더 쉽게 적응할지도 모름
    • 이런 견해를 내면 Zig 진영에서 싫어할 걸 알지만, vim이나 VS Code 같은 곳에서 zig fmt를 끌 수 있게 되면 다시 Zig에 기대를 걸겠음
      스타일 선호가 강제가 되면 입맛이 씁쓸함. 언어를 도구로 쓰는 개발자들을 존중하지 않는 태도처럼 느껴짐. 커뮤니티 참여와 다른 관점에 대한 개방성에 더 깊은 문제가 있다는 신호일 수도 있고, Zig에는 실제로 그런 문제가 있어 보임[0]
      코드 일관성이 필요한 회사는 린터를 돌리면 충분하고, 주말 프로젝트에서는 내 스타일 선호 말고는 아무 관심도 없음. Zig가 성인을 위한 언어인지 아닌지의 문제임. 어차피 특정 방식으로 코딩을 강요받을 거라면, 무료로 메모리 안전성까지 주는 Rust를 쓰지 않을 이유가 없음
      [0] https://github.com/ziglang/zig/issues/16270
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.