Bun의 Rust 재작성에 대한 제 생각

 (andrewkelley.me)
6P by GN⁺ | ★ favorite | 댓글 2개
  • Zig 창시자 Andrew Kelley는 Bun의 Rust 재작성을 언어 기능의 승패보다 Zig 소프트트웨어 재단(ZSF)과 Bun/Oven 사이의 관계 붕괴가 드러난 사건으로 해석함
  • 초기 Bun은 Zig를 성능 성과의 기반으로 인정하고 ZSF에 연 $60,000 규모로 기부했지만, VC-backed 스타트업이 된 뒤 조직 운영과 코드 품질을 둘러싼 불만이 커짐
  • ZSF는 Bun 코드베이스에서 해킹성 구현, assertion 남용, 빠른 기능 추가에 비해 부족한 버그·기술 부채 정리를 우려했고, Bun이 Zig의 대표 사례처럼 보이는 상황도 부담으로 여김
  • Kelley는 Bun의 Rust 전환 글이 버그 감소를 스타일 가이드 vs 언어 기능 구도로 만든다고 비판하며, 실제 핵심은 버그 제거에 투입한 엔지니어링 시간과 코드 품질 관리라고 봄
  • ZSF는 Bun의 기부에 감사하지만 Anthropic 인수 뒤 기부와 관계가 끝났고, Rust 재작성으로 Zig와 Bun의 사업적 이해관계가 분리된 점을 긍정적으로 받아들임

Bun과 Zig의 초기 관계

  • Jarred는 약 5년 전 Zig 커뮤니티에 합류했고, Kelley는 그를 빠르게 시도하고 많이 배우는 “beginner energy”가 강한 사람으로 봄
  • Bun이 JavaScript 도구체인으로 주목받으면서 Zig에도 더 많은 관심이 모이기 시작함
  • Kelley는 Jarred가 크라우드펀딩만으로도 샌프란시스코 기준 안정적인 수입을 만들 수 있었을 것이라고 보지만, Thiel Fellowship식 사고방식과 Silicon Valley식 접근을 받아들여 벤처캐피털을 택했다고 봄
  • 초기 Bun은 Zig 프로젝트에 우호적이었음
    • Bun 웹사이트에서 성능 성과에 Zig를 인정함
    • Zig Software Foundation에 연 $60,000 규모의 월간 기부를 설정함
    • Bun의 Rust 재작성 글에서도 Zig 프로젝트에 대한 감사가 진심처럼 보인다고 평가함

VC-backed 스타트업이 된 뒤의 균열

  • Bun이 VC-backed 스타트업이 된 뒤 Jarred는 커뮤니티와 함께 오픈소스를 키우는 개발자에서 사업 운영자에 가까워짐
  • Oven의 채용 메시지는 초기 약 9개월 동안 강도 높은 업무를 예고했고, work-life balance가 “일하지 않는 시간이 많다는 뜻”이라면 맞지 않을 수 있다고 밝힘
  • Kelley는 Oven 면접자와 직원들과 대화하며 Jarred의 관리자 역할에 대한 부정적 메시지를 반복해서 들었다고 함
    • 문제로 거론된 항목은 의사소통 부족, 비현실적 기대, 낮은 공감, 경험 부족임
  • 그 결과 Zig로 일하고 싶어 하던 커뮤니티 구성원들이 Oven과 Bun을 피하게 됨
  • Jarred가 생산성과 스타트업 exit 전략에 집중할수록 Kelley의 Zig 장기 비전과는 멀어짐
    • 예로 Jarred는 Language Server Protocol 구현과 VSCode 통합을 우선해 달라고 요구했지만, Kelley에게는 더 큰 계획이 있었음

ZSF가 본 Bun 코드 품질 문제

  • Kelley가 꼽은 핵심 문제는 코드 품질임
  • Zig 팀은 사용자 프로젝트의 소스 코드를 읽고, 언어 변화가 사용자에게 어떤 영향을 주는지 확인하며, 변경으로 인한 파손과 성능 회귀를 테스트함
  • Bun 코드베이스에서는 ZSF가 우려한 프로그래밍 관행이 늘어남
    • 해킹성 구현이 계속 쌓임
    • assertion 남용이 있었음
    • 기능을 빠르게 추가하는 데 비해 성찰, 버그 제거, 기술 부채 해소 시간이 적었음
  • Kelley는 Bun의 이런 방식이 Zig에 대한 메모리 안전성 비판과 결합될 수 있다고 우려했고, Zig 프로젝트와 사회적 거리를 두고 싶어 함
  • ZSF는 Bun을 더 나은 프로그래밍 관행으로 이끌려 했지만 효과를 내지 못함

Anthropic 인수와 Rust 재작성

  • ZSF 내부에서는 Bun이 순손실(net liability) 에 가깝다는 판단이 생김
  • Bun이 Zig의 대표 사례처럼 보이지만, 실제로는 “Zig 코드를 이렇게 쓰면 안 된다”는 예시에 가깝다는 점이 부담이었음
  • Kelley는 Bun의 “cloud 무언가를 판다”는 사업 계획을 처음부터 허술하게 봤고, 언젠가 매각되면 Zig도 간접적으로 부정적 홍보를 받을 수 있다고 봄
  • Anthropic 인수 뒤 ZSF는 안도함
    • 기부가 조용히 중단됐고, ZSF는 이를 예상하고 있었음
    • Bun 측은 월간 미팅을 취소하지도, 참석하지도 않았고 관계는 끝난 것으로 받아들여짐
  • ZSF는 며칠 안에 Rust 재작성이 올 것이라고 의심했고, 이를 응원함
  • Anthropic 인수 뒤 Claude가 Bun으로, Bun이 Zig로 작성됐다는 간접 연결만으로도 Zig 커뮤니티에 부담이 생김
    • drive-by slop contributions가 늘어남
    • LLM 출력을 포럼 글에 붙여 넣는 AI 열성 사용자들이 유입됨
    • Kelley는 Zig가 AI와 연결된 프로그래밍 언어로 알려질까 우려함
  • Jarred가 Rust 재작성을 발표하자 Kelley는 이를 매우 반겼고, 이제 “내 문제가 아니다”라는 감각을 표현함

Bun의 Rust 재작성 글에 대한 반박

  • Kelley는 Bun의 Rust 재작성 글이 잘 쓰였다고 보면서도, 몇 가지 핵심 문제를 지적함

  • 버그 감소의 핵심

    • Bun 글은 버그를 피하려면 스타일 가이드와 프로그래밍 언어 기능 중 하나를 골라야 하는 것처럼 구도를 만듦
    • Kelley에게 버그 제거의 주된 방법은 엔지니어링 자원을 투입해 버그를 찾고 없애는 일임
    • TigerBeetle은 시간을 들여 버그를 찾고 제거했으며 ZSF와 건강한 관계를 유지했지만, Bun은 둘 다 하지 않았다고 봄

  • 테스트 스위트에 대한 모순

    • Bun 글은 100만 줄의 검토되지 않은 코드를 배포할 수 있는 이유로 테스트 스위트가 충분하다는 점을 든다고 봄
    • Kelley는 그렇다면 Zig 코드에는 왜 성가신 버그가 많았는지, 테스트 스위트가 Zig 코드의 버그는 못 잡지만 100만 줄의 미검토 코드 버그는 잡을 수 있는지 되묻고 있음

  • 성능과 LTO

    • Bun 글은 성능 향상을 LTO에 돌리지만, Zig는 Bun의 전체 기간 동안 LTO를 지원했다고 함
    • Zig는 과거 LTO를 기본 활성화했으나 LLVM 버그가 너무 많아 기본값에서 제외했고, 그 버그들은 Rust에도 영향을 준다고 함
    • Kelley는 ZSF가 LTO 활성화를 권했을 가능성이 높고 Bun이 듣지 않았을 것이라고 봄

  • fuzzing

    • Bun 글은 Zig 코드에 대해 성실히 fuzzing을 한 것처럼 암시하지만, Kelley는 통화에서 Bun 팀이 아무것도 fuzzing하지 않는다고 말했다고 함

  • 바이너리 크기와 comptime

    • Bun 글은 바이너리 크기를 줄이기 위한 여러 엔지니어링 작업을 Rust 재작성의 근거처럼 제시하지만, Kelley는 그 작업들이 재작성 자체와 무관하다고 봄
    • 해당 작업들은 처음부터 Zig 코드베이스에서 했어야 할 엔지니어링 작업에 가까움
    • ZSF는 몇 년 동안 Bun의 comptime 남용을 경고했고, comptime/inline 사용량과 컴파일 시간을 감사할 수 있도록 time report 기능도 만듦

  • 컴파일 속도

    • Kelley는 Bun 글이 컴파일 속도를 언급하지 않았다고 지적함
    • Zig 컴파일러 프로젝트는 약 600,000줄로 재작성 전 Bun과 비슷한 규모임
    • Kelley의 측정에서는 깨끗한 캐시에서 처음부터 빌드하는 데 16초, 증분 컴파일 활성화 후 각 후속 편집에는 90ms가 걸림
    • Rust 재작성 후 Bun의 대응 측정값이 무엇인지 묻고 있음

Kelley의 결론

  • Kelley에게 핵심 문제는 프로그래밍 언어 기능이 아니라 관계 붕괴임
  • ZSF는 Bun으로부터 받은 기부에 진심으로 감사하며, 그 돈을 Zig 기여자 보상에 사용함
  • Kelley는 Jarred 개인을 악의적으로 비판하려는 것은 아니라고 선을 그음
    • Jarred는 자신과 취향과 삶의 목표가 다르지만, 자신이 원하는 삶을 성공적으로 만들었다고 봄
    • Jarred가 행복하고 성공했다고 받아들이며, 악의를 갖고 있지 않다고 함
  • 다만 Kelley는 ZSF와 Bun의 사업적 이해관계가 더 이상 얽히지 않게 된 점을 기쁘게 여김
  • Rust 재작성의 좋고 나쁨을 언어 선택 기준으로 다투는 공개 논쟁이 끝나면, 양측의 상호작용도 끝난다고 봄

함께 보면 좋은 글 β

click   [-]

글을 읽어보니 zig도 bun 도 둘다 쓰고싶지 않아지네요

답변달기
GN⁺   [-]
Hacker News 의견들

  • Andrew의 코드를 읽으며 정말 많이 배웠고, 원문에서도 말했듯 Zig 없이는 Bun도 없었을 것임
    “글에서는 Zig 코드를 퍼징했다고 주장하지만, 통화 중 Bun 팀 전체가 아무것도 퍼징하지 않는다고 말했다. 이는 노골적인 조작으로 보인다”는 부분에 대해서는 Fuzzilli 통합 PR이 있음: https://github.com/oven-sh/bun/pull/24826
    Fuzzilli가 Bun의 Zig 코드에서 찾은 문제를 고친 병합 PR들도 있음: https://github.com/oven-sh/bun/pull/28926, https://github.com/oven-sh/bun/pull/28934, https://github.com/oven-sh/bun/pull/29255, https://github.com/oven-sh/bun/pull/29210, https://github.com/oven-sh/bun/pull/29199
    “Fuzzilli”로 검색하면 더 많은 PR이 나옴: https://github.com/search?q=repo%3Aoven-sh%2Fbun+is%3Apr+Fuz...

    • Andrew가 말한 건 아마 zig build test --fuzz, 즉 Zig 내장 퍼저였을 것 같고, 그의 범위 안에 있는 도구는 그쪽임
    • 잘 이해가 안 됨. “Zig 코드를 퍼징했다”는 말이 Bun에 Fuzzilli 통합을 추가한 것과 어떤 식으로 관련되는 건가?
    • 이 논쟁에서 딱히 어느 쪽 편도 아니지만, Andrew의 글에서 특정 세부사항 하나만 짚고 나머지는 전혀 다루지 않는 건 좀 무의미해 보임
      둘 중 누구도 숭배하지 않고, 그냥 전체 대화가 더 나은 방향으로 가기보다 악화되는 것처럼 보여서 궁금함
    • 링크들은 퍼저를 썼다는 건 보여주지만, Andrew 발언의 다른 절반에는 답하지 않음. Andrew가 통화 내용을 잘못 전달했거나 잘못 기억한 건가?
      사실 확인 질문을 했다는 이유로 비추천을 받는 건 꽤 의미심장함. “최근까지는 퍼저를 쓰지 않았으니 둘 다 맞다” 같은 간단한 답일 수도 있는데, 몰라서 묻는 것뿐임

  • 이 글은 Zig에게 비전문적이고 민망한 일임
    Jarred에 대해서는 거의 모르지만, 어제 읽은 그의 글은 Zig에 감사하는 분위기였고, 이제 보니 Zig에 상당한 금액도 기부했음
    이 글 전체는 다른 제품을 선택했다는 이유로 그를 공개적이고 개인적으로 공격하고 있음
    Andrew가 이 글이 Zig를 해명해 줄 거라고 생각한다면 이상하고, 실제로는 유치해 보이게 만들 뿐임. 아니면 그냥 Jarred를 공격하고 싶은 건지도 모르겠음

    • 개인 블로그에서 자신에게 소중한 사안에 대해 솔직한 개인 의견을 말하는 게 왜 비전문적인지 모르겠음
      모두가 걸어 다니는 브랜드가 되어 항상 말을 걸러야 하고, 살얼음판을 걸으며, “전문적”으로 보이려고 회사식 표현 뒤에 숨어야 하나?
      지금 세상에는 덜 솔직한 담론이 아니라 더 솔직한 담론이 필요하고, 온라인 상호작용은 점점 진정성이 줄어드는 것 같음
    • 맞음. 그래서 Anthropic과 Bun이 Zig에서 떠난 것임
      Zig는 사실상 1인 프로젝트에 가깝고, 그 한 사람이 점점 더 불안정한 결정을 내리고 있음
      물론 자기 프로젝트이니 권리는 있지만, 거의 조 단위 가치의 회사라면 이런 공급망 위험을 맞고 싶지 않을 것임
      Anthropic 입장에서는 Zig 생태계에 더 투자하기보다, not-so-BDFL이 선을 넘을 위험이 드러난 시점에서 싹을 자르는 편이 나음
    • Antirez는 “테스트 커버리지를 늘리기 위해 AI를 쓰지 않는 건 어리석다”에 가까운 글을 썼음
      반면 Zig는 채택 규모와 개발 기간을 고려하면 테스트 커버리지가 민망할 정도로 낮음
      AI에 대한 Zig의 태도는 완전히 유치함. 크게 이득을 볼 수 있는데도 어떤 활용 가능성도 검토하지 않음
      PR 스팸을 막으려는 것과, 손발을 묶고 내부에서도 가장 쉬운 고효용 영역에 AI를 전혀 쓰지 않는 건 다름
      AI로 PR 스팸 속 실제 버그 후보를 선별할 수도 있는데, 도움을 전혀 받지 않으니 실제 버그가 필요 이상으로 오래 방치됨
    • 글은 Rust로의 전환을 오히려 반기는 것처럼 보임. 그 점은 글에서 여러 번 반복되고, Bun이 Zig를 떠나기를 기다리고 바랐던 것처럼 보이기도 함
    • 동의함. 이 글은 직장에서 문서로 쓰기 어려운 개인 비판들을 늘어놓기보다 냉정한 사실에 집중했어야 함
      안타깝게도 이런 식으로 쓰는 데 너무 편한 오픈소스 개발자가 많고, 내가 오픈소스 활동을 그만둔 이유 중 하나임
      합리적인 직장이라면 이런 식으로 행동하면 해고되거나 최소한 징계를 받을 것임

  • “Jarred에 대한 개인적 비판은 없다”는 문장은, 거의 전부가 얇게 가려진 개인 비판처럼 보이는 글 끝에서 하기엔 꽤 강한 말임
    누군가에게 초보자 에너지가 있다고 하면서 “실패하고 배우는 사람”처럼 가짜 긍정으로 포장하거나, 소문상 “냄새나는 관리자”라고 불린다고 쓰는 식임
    “내가 나쁘다고 하는 건 아니지만, 모두가 이 사람이 나쁘다고 동의한다는 걸 블로그에 써야겠다”에 가깝고, 사실이라도 매우 취향이 나빠 보임

    • “냄새나는 관리자”라고 부르는 게 개인 공격인지 헷갈림. 사람과 그 사람의 “업무”를 구분하지 못한다는 게 재미있음
      나도 형편없는 관리자들과 일하지만, 개인적으로 원한을 품지는 않음
    • 글 나머지에 이런 인신공격이 들어 있는데 “개인적 비판은 없다”는 건 일관성이 없음
      “소문망은 크고 건강했으며 즙 많은 포도로 가득했고, 그 포도들의 즙은 모두 같은 메시지를 담고 있었다: Jarred는 냄새나는 관리자였다”
      “Jarred는 LLM을 쓰기 전부터 이미 찌꺼기 같은 글을 쓰고 있었다”
      이상할 정도로 유치한 글임. 회사식 필터를 거치지 않고 속내를 말하는 글을 좋아하긴 하지만, 그런 글은 그 사람이 어떻게 생각하고 움직이는지도 보여줌
      좋은 리더십이라면 회사식 필터를 걷어내도 결과는 여전히 전문적인데, 이 글은 그보다 훨씬 못한 무언가를 드러냄
    • 초보자 에너지가 가짜라는 건가? 사이드 프로젝트에서는 초보자 에너지를 즐김. 실패하고 배움
      안전하고 의존하는 사람이 없을 때는 완전히 정상임. 관리 업무와는 다름

  • Anthropic 인수가 끝나자 ZSF가 안도의 한숨을 쉬었다는 대목이 인상적임. 기부가 조용히 중단됐을 때도 계좌는 준비돼 있었고, 월례 미팅을 취소하지도 않고 나타나지도 않았을 때도 놀라지 않았다는 것임. 관계는 끝난 상태였음
    이런 일은 여러 번 봤음. 프로젝트나 조직이 인수되면 그들이 하던 “좋은 일”은 요란하게 종료되는 게 아니라, 후원자가 조용히 무시하기 시작하면서 그냥 사라짐
    그들이 징후를 읽고 대비했다니 다행임. 직접 힘들게 배울 필요는 없는 훌륭한 교훈이고, 한두 큰 기부자에 의존하는 자유·오픈소스 프로젝트는 주의해야 함
    앞으로 개발자 도구 생태계에서 이런 일을 훨씬 더 많이 보게 될 것 같음

  • 이 스레드 다른 곳에 글의 어조에 대한 날카로운 반응들이 있지만, 이 글로 Zig에 대한 기대가 꺾였음
    드라마는 재미있고 Andrew의 진심은 어쩌면 존경할 만하지만, 진지한 프로젝트에 필요한 전문성은 이런 게 아님
    지루하고 영감 없어 보여도, 기술 스택과 그 운영에는 그런 안정감을 원함
    Jarred가 순손실이었을 수도 있지만 Bun은 Zig를 쓰던 아주 큰 프로젝트였고, 그 프로젝트가 떠나는 건 Andrew가 말하는 것만큼 Zig에 좋은 일이 아님
    그는 언어의 성장보다 순수성과 이념에 훨씬 높은 우선순위를 두는 것처럼 보임. 진지한 프로그래밍 언어에는 채택과 임계 규모도 중요한 요소임

    • 프로젝트의 진지함이 저자가 개인 블로그에서 선택한 표현과 얼마나 관련 있는지 바로 와닿지 않음
      Linus의 이메일 말투 때문에 Linux가 진지한 프로젝트가 될 수 없었다고 말하는 것과 비슷함
    • 화가 나는 건 이해됨. 감정을 느끼고 그 감정의 신호를 보이는 것 자체를 문제 삼는 듯함
      심지어 직접적으로 쓴 것도 아니고 개인 블로그에 쓴 글임
    • 이 글이 Andrew Kelley가 Zig 같은 진지한 프로젝트를 운영하기에 전문성이 부족하다는 걸 어떻게 설득했는지 모르겠음
      중요한 건 그가 언어에 기여한 바 아닌가?
    • 이 지점은 핵심 반론에 가깝지만 살짝 지나침. 전통적인 해커 문화와 VC식 성장 해킹 사고방식의 충돌임
      왜 반드시 채택과 임계 규모가 중요한가? 더 넓은 채택을 포기하더라도 자신이 원하는 순수성과 이념에 맞는 언어를 만들면 안 되는 이유가 뭔가?
      왜 모든 것이 사용자 성장과 인지도에 최적화되어야 하나?
    • 이 경우 Bun은 Anthropic에 인수됐음. Zig를 떠난 것이 반드시 기술적 장점 때문이라고 볼 수는 없음
      그들이 그렇게 가장한다고 해도 말임

  • 이 글은 매우 신선했음. Bun 글의 PR식 표현을 더 세련되게 받아치는 유혹이 컸을 텐데 그러지 않았음
    Jarred에게 부정적으로 보이는 사실들을 넣되 자기 의견은 조심스럽게 숨기는 식, 예컨대 “사람들이 그를 냄새나는 관리자라고 부른다고 들었다. 내가 그런다는 건 아니고, 다른 사람들이 그런다” 같은 방식도 가능했을 텐데, 그냥 솔직해서 좋았음

    • 저자가 자기 성격과 생각을 숨기려 하지 않는 점은 신선함
      다만 그 성격과 생각의 내용은 꽤 받아들이기 어려움
    • 그냥 긴 인신공격처럼 보임
    • 동의함. 이 블로그 글은 PR식 말투와 x.com 사이의 균형을 잡은 느낌임

  • 글의 첫 번째이자 가장 큰 부분을 추측성 인신공격에 할애한 탓에, 저자의 말에 신뢰를 싣기 어려움
    Zig의 장점을 정리할 좋은 기회였음. mitchellh의 전도와 영감을 주는 글 때문에 최근 Zig를 배워보고 싶었는데, 이 글은 Zig를 배우고 싶은 마음을 식게 만듦

    • 그렇게 느끼는 사람이 혼자가 아닌 것 같음. 정확히 어떤 부분이 “추측성 인신공격”처럼 보였는지 원문 그대로 인용해 줄 수 있나?
      Andrew가 Jarred와 그의 작업 방식·업무 태도를 어떻게 보는지에 대한 내용은 꽤 보이지만, 무엇이 인신공격인지, 추측인지 아닌지는 명확히 안 보임
    • 그 저자가 Zig의 저자라는 점이 문제임

  • Jarred에 대한 개인 공격이 Zig를 쓰자는 주장에 별로 도움이 되는 것 같지 않음
    언어에 집중했어야지 “냄새나는 관리자” 같은 표현을 쓰면 안 됐음
    솔직히 이 글을 보면 Jarred만큼이나 Andrew도 피하고 싶어짐

    • 이건 Jarred 개인이 아니라 그의 공개적이고 비전문적인 행동에 대한 비판임
      최근 몇 달 동안 커뮤니티의 많은 사람이 목격한 일이기도 함
      “Jarred가 직업적 역할에서 우리 커뮤니티의 많은 사람을 떠나게 했고, 우리는 거리를 두고 싶다”는 말은 “Jarred는 사적으로 나쁜 사람이다”가 아님
      물론 이 바닥에서는 VC들이 일 밖의 사생활을 얼마나 남겨뒀을지 생각하면 거의 같은 뜻처럼 받아들여질 수도 있지만, 그건 Andrew의 문제가 아님
      Andrew의 문체를 옹호하진 않음. 더 넓은 신경전형 독자에게 말할 때는 자신의 신경다양성을 좀 더 가릴 수도 있었을 것 같음
      그래도 그의 프로젝트이고, 그의 커뮤니티는 이미 알고 있는 특성이며, 이것도 알려진 변수임
      “Andrew가 Jarred의 인격을 암살하려 한다”는 부차적 속뜻을 붙이지 말고, Andrew가 완전히 진심이라고 가정하고 다시 읽어보면 도움이 될 수 있음
    • Andrew의 온라인 사회적 행동은 대체로 옹졸함의 연속처럼 보임
      노골적으로 악의적이라고 느낀 글을 본 게 이번이 처음도 아님. 완곡하게 “직설적”이라고 부를 수준이 아님
      “침묵은 선택지가 아니었나?”

  • “Jarred에 대한 개인적 비판은 없다”는 말과 달리, 글 전체가 Jarred에 대한 개인 비판처럼 느껴졌음

    • 개인적 비판이라기보다는 Jarred에 대한 직업적 비판으로 봄. 한 개인에게 초점이 맞춰져 있긴 해도 아주 사적인 내용은 아니라고 생각함
    • 문자 그대로 세 문장 뒤에 다시 “생산성 판타지 열병 꿈”이라고 모욕함
      설령 사실이라도 이 형태로 공개하는 건 현명하지 않음. 목표가 Zig를 방어하는 것이었다면 덜 개인적인 방식으로도 가능했음
    • 그 부분은 잘못 쓴 것 같고 수동공격적으로 보이지만, 아마 Jarred에게 무례했다고 인터넷의 천사들이 분노할까 봐 겁났던 것 같음

  • Bun을 Zig에서 Rust로 다시 쓰는 이 전체 작업은 큰 마케팅 행보처럼 보임
    Anthropic AI가 정말 그렇게 강력하다면, 왜 버그를 고치고 기존 Bun Zig 코드베이스를 재설계해서 현재 버그뿐 아니라 비슷한 버그가 앞으로 생기지 않게 하는 더 야심 찬 작업을 맡기지 않는가?

    • 재작성의 유일한 이유는 Zig 창시자가 AI 기여를 받지 않겠다고 발표했기 때문임
      그게 Anthropic의 감정을 상하게 한 것임
    • 이 이상한 움직임이 Anthropic에서 나온 건지, 아니면 성사된 뒤에도 더 팔아보려던 과열된 창업자에게서 나온 건지 궁금함
      Anthropic이 이런 장치 없이도 Bun을 인수하고 싶어했을 수 있다고 상상할 수 있음
    • Rust로 다시 쓰기 전에 Bun은 컴파일을 가속하는 포크를 유지했고, 질문한 사람들에게 이 포크는 Zig의 LLM 금지 정책 때문에 절대 병합될 수 없다고 알렸다는 점은 주목할 만함
      몇 주 뒤 Bun은 Rust 재작성을 시작했음. 명시되진 않았지만 두 사건이 관련돼 있을 수 있다고 봄
    • Rust는 인간과 LLM 모두에게 그런 검사 상당수와 RAII 같은 도구를 공짜로 제공하는 바로 그 도구임
    • 결국 Claude가 그 버그들을 고칠 수 없거나, 고칠 수 있는데 Bun 팀이 일부러 고치지 않기로 한 것임
      어느 쪽이 더 나쁜지는 모르겠음
답변달기