▲

Bun의 Rust 재작성 PR이 머지됨

 (github.com/oven-sh)
9P by GN⁺ 11시간전 | ★ favorite | 댓글 4개
  • PR #30412는 Bun을 Rust로 재작성하는 변경으로, 2026년 5월 14일 claude/phase-a-port 브랜치에서 main으로 머지됨
  • 변경 규모는 6,755개 커밋, 2,188개 파일, +1,009,257/-4,024 라인으로 표시됨
  • Jarred-Sumner는 상세 내용이 담긴 블로그 글이 곧 나온다고 밝힘
  • 이 변경은 Bun의 기존 테스트 스위트를 모든 플랫폼에서 통과하며, 여러 메모리 누수와 불안정한 테스트를 고쳤다고 설명됨
  • 바이너리 크기는 3MB~8MB 감소했고, 벤치마크는 중립적이거나 더 빠른 범위라고 설명됨
  • 가장 중요한 이유로, 팀이 수년간 큰 개발·디버깅 시간을 쓴 메모리 버그를 컴파일러 보조 도구로 잡고 예방할 수 있게 됐다고 제시됨
  • 코드베이스는 대체로 동일하며, 아키텍처와 자료구조도 그대로 유지됐다고 설명됨
  • Bun은 여전히 서드파티 라이브러리를 적게 사용하며, async Rust는 사용하지 않는다고 명시됨
  • 사용자는 bun upgrade --canary로 이 변경을 시험해볼 수 있음
  • Jarred-Sumner는 문제가 생기면 이슈를 올려달라고 요청했고, 스레드가 과열되면 잠글 수 있다고 밝힘
  • 비-canary 버전에 들어가기 전 아직 최적화 작업이 남아 있음
  • 정리 작업도 아직 남아 있으며, 이는 후속 PR 시리즈로 진행될 예정임

함께 보면 좋은 글 β

▲
xguru 11시간전  [-]

와 백만라인짜리 PR 머지. Zig에서 Rust로 그냥 한번에 넘어가네요.
이거 머지될지 안될지 몰라요~~ 라고 얘기하더니, 일주일만에 잘 동작하던 코드를 한방에 언어교체 ㅎㅎ
뭔가 AI어시스트 코딩 때문에 기념비 적인 일이 일어나는 느낌.

답변달기
▲
heycalmdown 6시간전  [-]

진짜요 그냥 테스트 하는거고 안 쓸 가능성이 높다고 하더니

답변달기
▲
freedomzero 6시간전  [-]

zig에서 안해주니까 바로 러스트로 넘어가는 대범함 ㄷㄷ

답변달기
▲
GN⁺ 11시간전  [-]
Hacker News 의견들

  • 발표에서 리라이트가 1주일 걸렸다고 하면, Zig 관용구를 Rust 관용구로 매핑하는 이 매우 상세한 지침 파일을 준비하는 데는 시간이 얼마나 들어갔는지 궁금해짐: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...
    게다가 Pointers & ownership와 Collections 섹션을 보면 Bun 코드베이스는 이미 내부 스마트 포인터 타입을 써서 Rust 대응물과 1:1로 매핑되도록 준비돼 있었고, bun_collections Rust 크레이트도 이미 존재함
    이 리라이트는 오래전부터 준비돼 있었고 Anthropic 인수 협상 중 Bun 팀이 제안한 것처럼 보임

    • LLM 관련 글을 읽을 때 뭐가 사실인지 모르겠고, 여기 Hacker News 댓글도 마찬가지임
      걸린 돈이 너무 크니 커뮤니티에 마케팅 알바를 심을 유인이 분명하고, 일부는 그냥 진영 논리에 빠져 있음
      Anthropic이 Bun을 소유한 이상, 이 작업이 실제보다 쉬워 보이게 만들 유인도 충분함
    • 결과로 나온 Rust 코드의 품질이 좋은지, 줄 수가 적절한지, 코드베이스가 애초에 이 작업에 얼마나 준비돼 있었는지 같은 요소를 제쳐두면, 약 100만 줄 출력의 일관성이나 품질을 높일 수 있는 선행 산출물로 622줄짜리 문서는 상대적으로 작은 비용이라고 볼 수 있지 않나 싶음
      출력 규모가 워낙 커서 여기에는 곱셈 효과가 있어 보임
      다만 이 규칙을 만들기 위해 얼마나 많은 암묵지가 필요했는지, 이 파일을 얼마나 반복 개선했는지도 궁금함
      예를 들어 이 규칙 중 얼마나 많은 것이 번역 반복 과정에서 만난 실패 사례에서 나온 것인지 알고 싶음
    • using internal smart pointer types that map 1-to-1 to Rust equivalents라고 했지만, 스마트 포인터는 Rust가 발명한 게 아님
      포인터가 있는 다른 언어로 코드를 짜면 이미 머릿속으로 같은 타입들을 모델링하고 있음
      그리고 bun_collections Rust 크레이트가 이미 있었다는 건 틀렸음
      코드베이스의 PR 일부일 뿐이고, 이전부터 존재한 게 아님
    • 이건 Anthropic의 gcc 시연 때와도 같음
      의심을 덜고 IPO 분위기를 더 띄우는 건 아주 쉬울 텐데, AI를 몰아가기 위해 필요했던 숨은 작업을 별도 저장소로 공개하고 모두가 결과를 재현하게 하면 됨
      결국 고객들이 이루려는 것도 “7일” 만에 쓸 수 있는 코드 100만 줄 아닌가
      모두가 자기 워크플로에 재현해 보면서 Anthropic 사용량 지표도 올라갈 것임
      정말 멋진 결과였다면 링크와 지침이 달린 블로그 글부터 냈을 것 같음
      지금 이 순간 블로그 글이 작성 중이라 내가 틀렸음이 증명될 수도 있긴 함
    • Zig 버전 Bun에는 기존 Rust 포인터 타입에 깔끔하게 매핑되는 포인터 타입이 3개 있었던 것 같고, 나머지 7~8개는 새 타입을 만들어야 했던 듯함
      그게 음모론의 핵심인가
      bun_collections도 포팅 가이드보다 훨씬 오래돼 보이진 않음

  • +1009257 -4024라니, Bun은 이제 Rust 코드 100만 줄을 넘김
    Rust 컴파일러 자체의 크기에 가까워지고 있음
    다만 BunJS는 대체로 JavaScript 인터프리터 래퍼와 NodeJS 라이브러리 재구현, 즉 Rust 표준 라이브러리 래퍼에 가까움
    BunJS는 LLM 시대의 소프트웨어 복잡도 관리를 보여주는 카나리아가 되어가는 것 같음

    • mostly a JavaScript interpreter wrapper는 정확하지 않음
      Bun은 배터리 포함 JavaScript 및 CSS 트랜스파일러(파서), 축소기, 번들러, npm 같은 패키지 관리자, Jest 같은 테스트 러너이고, 내장 Postgres, MySQL, Redis 클라이언트 같은 런타임 API도 갖고 있음
      자연히 코드가 엄청 많아질 수밖에 없음
    • Bun은 JavaScript 인터프리터가 아니라 NodeJS 라이브러리와 여러 다른 라이브러리의 재구현에 가까움
      Bun은 JavaScriptCore를 JS 엔진으로 사용하므로 Bun 자체는 JavaScript 파싱, 해석, JIT를 하지 않거나 적어도 하지 않아야 함
      수정: 잘못 읽었음. “JavaScript interpreter wrapper”라고 했으니 맞는 표현임
    • iOS에서 전화번호로 감지되는 게 앞의 + 때문인지 다른 요인도 있는지는 모르겠지만, 모바일에서는 줄 수 변경량에 밑줄이 생기고 탭하면 전화를 걸 수 있음
      diff 크기 때문에 그런 거라면 꽤 웃김
    • Bun 코드베이스는 리라이트 전에도 비슷한 코드 줄 수였음
      리라이트 결과가 비슷한 LOC로 나오는 건 이상한 일이 아님
    • JavaScriptCore 래퍼가 100만 줄이라는 건 에이전트가 무엇을 할 수 있는지 보여주는 훌륭한 예임

  • $ rg 'unsafe [{]' src/ | wc -l 결과가 10428이고, $ rg 'unsafe [{]' src/ -l | wc -l 결과가 736임
    언어별로는 Rust 1443파일 929213줄, Zig 1298파일 711112줄, TypeScript 2604파일 654684줄, JavaScript 4370파일 364928줄, C 111파일 305123줄, C++ 586파일 262475줄, C Header 779파일 100979줄임

    • Rust에서는 잠재적으로 안전하지 않은 코드를 이렇게 특정해서 검색할 수 있다는 점은 좋음
      Zig에서 안전하지 않은 코드는 어떻게 검색함?
      아니면 그냥 어디에나 있다고 가정해야 하나
    • 파일 절반에 unsafe 키워드가 들어간다면 좋은 리라이트처럼 보이지 않음
      코드의 절반 가까이가 여전히 unsafe라면 Rust로 리라이트하는 의미가 뭔가
    • Mythos가 자기들 주장처럼 세계 최고이길 바람. 이제 정말 필요할 테니까
    • 집에 메모리 안전성 있어!
      집에 있는 것: 10428

  • 아직 이 내용을 다룬 블로그 글을 쓰는 중이고, 더 자세히 공유할 예정임
    배경이 궁금하면 Bun v1.3.14와 그 이전 릴리스 노트의 버그 수정 목록을 훑어보면 됨
    Rust가 이 전부를 잡아주진 않음. 참조를 너무 오래 잡고 있어서 생기는 누수나 JS 경계를 넘어 재진입하는 모든 문제는 여전히 우리가 책임져야 함
    하지만 그 목록의 상당수는 use-after-free, double-free, 오류 경로에서 해제를 잊는 문제이고, 이런 것들은 컴파일 오류가 되거나 자동 정리로 바뀜

    • 9일 전에 이렇게 말했었음[0]:
      I work on Bun and this is my branch
      This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
      어쩌면 과잉반응이 아니었을지도?
      [0]: https://news.ycombinator.com/item?id=48019226
    • 블로그 글이 기대됨
      버그를 걸러내기 위해 Zig와 Rust 바이너리를 폭넓은 실제 애플리케이션에서 나란히 돌리거나, 가능하면 프로덕션에서 섀도 실행할 계획이 있는지 궁금함
    • 유료 고객이라면 이 작업 비용이 얼마나 들지 궁금함
      대략적인 추정치를 줄 수 있나
    • 두 바이너리를 비교하는 일종의 종단 간 퍼즈 테스트를 구현했거나 구현할 계획이 있는지 궁금함
      이 릴리스를 사용자 워크플로를 깨지 않게 내보내기 위한 구체적인 계획도 있는지 알고 싶음
    • 이게 Bun Workers API의 안정성 문제를 고칠 가능성이 있나? https://bun.com/docs/runtime/workers

  • 약 9일 전에 Jarred는 이게 병합될지 전혀 확실하지 않고 과잉반응이라고 썼음
    아이러니함

    • 오픈소스 리더십의 모범 사례 같음
      Linus가 Linux 커널을 리라이트하지 않겠다고 말해놓고 어느 날 일어나 전체를 기계 보조 Rust 리라이트로 병합했다면 어떤 난리가 났을지 상상해보라
    • 회사를 더 이상 소유하지 않게 되면, 본인이 하는 말은 안전하게 무시해도 됨
      쓴 토큰 비용을 정당화해야 할 게 뻔했음
    • 그렇다고 병합될 가능성이 배제되는 건 아님

  • 와, 앞으로 지켜보는 재미가 있겠음
    이 코드가 검토됐을 가능성은 전혀 없지만, 어쩌면 이제는 모델이 코드를 쓰고 검토하는 걸 믿을 수 있는 포스트 휴먼 시대에 들어섰는지도 모름
    이건 Gastown 같지만 훨씬 더 유명한 프로젝트에서 벌어진 일임
    앞으로 이 프로젝트가 새 기능을 어떻게 추가할 수 있을지, 아니면 추가 자체가 가능할지 흥미로움
    Anthropic이 Bun을 정확히 어떻게 쓰는지 아는 사람 있나?
    Claude Code의 일부인가?
    앞으로 Bun을 쓰는 게 꽤 걱정되는데, 그 걱정이 Claude 사용에도 어느 정도 적용되는지는 잘 모르겠음

    • 모델이 코드를 쓰고 검토하는 걸 믿을 수 있다는 건 절대 아님
    • 모든 테스트를 통과했음
      자동 언어 번역을 잡아낼 테스트 스위트를 믿을 수 없다면, 애초에 그 테스트 스위트를 전혀 믿으면 안 됨 :)
    • Anthropic이 Bun을 어떻게 쓰는지는 모르겠지만, 수백만 줄을 무작정 병합해도 괜찮다는 쪽으로 논의의 창을 옮기는 데 쓰는 것처럼 보임
    • 테스트 스위트는 어떤 상태인가

  • 자동 번역을 실험하는 건 사실 기대되지만, 하위 호환성 문제가 많이 생길까 봐 걱정됨
    커밋을 보기 시작했는데, 기본적으로 “테스트가 통과하지 않음” 문제를 테스트 자체를 바꾸는 식으로 해결하고 있음
    이미 배포된 프로그램에서 제대로 동작하게 만드는 진짜 작업은 이제 시작일 뿐임
    그나마 다행인 건 서버 쪽 JS 커뮤니티가 어떤 이유에서인지 이미 잦은 깨짐에 익숙하다는 점임

    • 내가 쓰는 런타임에 한 사람도 들여다보지 않은 코드가 들어간다는 생각은 불편함
      하지만 이게 큰 문제 없이 실제로 동작한다면 꽤 놀라운 일임
    • 이 결정들을 LLM이 했는지는 모르겠지만, Claude는 문제의 올바른 해법을 찾기보다 테스트를 수정하는 식의 수상한 행동을 더 잘 하는 경향이 있다고 항상 느꼈음
      GPT/Codex는 이 점에서는 더 정직함
    • 곧바로 안정 릴리스가 될 것 같지는 않지만, 틀렸다는 게 증명되면 기쁘겠음
      이 리라이트 전체에 회의적이고, Jarred Sumner는 인터넷 팔로워가 엄청나서 광고처럼 느껴짐
    • “테스트가 통과하지 않음” 문제를 테스트 자체를 바꿔 해결한다는 예: https://github.com/oven-sh/bun/pull/30412/changes/68a34bf8ed...
      훌륭함! 테스트에 임의로 sleep(1)만 추가하면 됨. 걱정하지 마, 다 잘될 거야!
    • 테스트를 훑어보면서 실제로 중요한 변경이 있었는지 보고 싶은데, GitHub가 diff조차 로드하지 못함

  • Bun을 쓰는 내 몇 안 되는 프로젝트는 다른 것으로 옮길 예정임
    이런 무모한 변경을 허용하는 거버넌스는 신뢰하지 않음

    • Deno는 훌륭한데, 그만큼 사랑받지 못한다고 생각함
      애초에 잘 작성됐기 때문에 리라이트할 필요도 없음
    • 나도 그냥 node를 계속 쓸 예정임
      한편으로는 불의 세례가 어떻게 될지 지켜보는 건 흥미롭겠고, 장기적으로는 결국 문제들이 해결될 것 같긴 함

  • 교육용으로 볼 만한 스레드가 있음. 일주일 전 Jarred가 다시 병합 결정에서 비켜나가고, 수많은 보병들이 곧 병합될 거라고 예측한 사람들을 공격했던 스레드임:
    https://news.ycombinator.com/item?id=48073680
    지금 보니 잘 버티지 못한 말이었지?

    • “이 스레드 전체가 과잉반응이다. 동작하지 않는 코드에 댓글 302개라니. 우리는 리라이트를 확정하지 않았다. 이 코드가 전부 버려질 가능성이 매우 높다”에서, 실험적 호기심 정도처럼 보이던 것까지 합쳐 10일 만에 전체 병합이라니 정말 미친 일처럼 보임
    • 세상에는 어느 장화를 핥는지는 별로 신경 쓰지 않는 권력 추종자가 얼마나 많은지 볼 때마다 놀라움

  • 이게 조금이라도 잘못되면, 자기 물건에 취한 마약상이라는 조롱이 끝도 없고 암울하게 이어질 것임

    • 조금도 잘못되지 않을 가능성에 감정적으로 준비되지 않은 사람이 너무 많음
    • 유출된 Claude Code 소스를 본 것만으로도 이미 조롱거리로 충분하지 않았나
    • 이미 자기 물건에 취해 있음
      Mythos 논문 읽어봤나? 의인화가 정말 심함
      그냥 싸구려 관심 끌기일 수도 있지만, 정말로 LLM이 의식이 있다고 믿는다면… 와우
답변달기