발표에서 리라이트가 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 바이너리를 폭넓은 실제 애플리케이션에서 나란히 돌리거나, 가능하면 프로덕션에서 섀도 실행할 계획이 있는지 궁금함
유료 고객이라면 이 작업 비용이 얼마나 들지 궁금함
대략적인 추정치를 줄 수 있나
두 바이너리를 비교하는 일종의 종단 간 퍼즈 테스트를 구현했거나 구현할 계획이 있는지 궁금함
이 릴리스를 사용자 워크플로를 깨지 않게 내보내기 위한 구체적인 계획도 있는지 알고 싶음
약 9일 전에 Jarred는 이게 병합될지 전혀 확실하지 않고 과잉반응이라고 썼음
아이러니함
오픈소스 리더십의 모범 사례 같음
Linus가 Linux 커널을 리라이트하지 않겠다고 말해놓고 어느 날 일어나 전체를 기계 보조 Rust 리라이트로 병합했다면 어떤 난리가 났을지 상상해보라
회사를 더 이상 소유하지 않게 되면, 본인이 하는 말은 안전하게 무시해도 됨
쓴 토큰 비용을 정당화해야 할 게 뻔했음
그렇다고 병합될 가능성이 배제되는 건 아님
와, 앞으로 지켜보는 재미가 있겠음
이 코드가 검토됐을 가능성은 전혀 없지만, 어쩌면 이제는 모델이 코드를 쓰고 검토하는 걸 믿을 수 있는 포스트 휴먼 시대에 들어섰는지도 모름
이건 Gastown 같지만 훨씬 더 유명한 프로젝트에서 벌어진 일임
앞으로 이 프로젝트가 새 기능을 어떻게 추가할 수 있을지, 아니면 추가 자체가 가능할지 흥미로움
Anthropic이 Bun을 정확히 어떻게 쓰는지 아는 사람 있나?
Claude Code의 일부인가?
앞으로 Bun을 쓰는 게 꽤 걱정되는데, 그 걱정이 Claude 사용에도 어느 정도 적용되는지는 잘 모르겠음
모델이 코드를 쓰고 검토하는 걸 믿을 수 있다는 건 절대 아님
모든 테스트를 통과했음
자동 언어 번역을 잡아낼 테스트 스위트를 믿을 수 없다면, 애초에 그 테스트 스위트를 전혀 믿으면 안 됨 :)
Anthropic이 Bun을 어떻게 쓰는지는 모르겠지만, 수백만 줄을 무작정 병합해도 괜찮다는 쪽으로 논의의 창을 옮기는 데 쓰는 것처럼 보임
테스트 스위트는 어떤 상태인가
자동 번역을 실험하는 건 사실 기대되지만, 하위 호환성 문제가 많이 생길까 봐 걱정됨
커밋을 보기 시작했는데, 기본적으로 “테스트가 통과하지 않음” 문제를 테스트 자체를 바꾸는 식으로 해결하고 있음
이미 배포된 프로그램에서 제대로 동작하게 만드는 진짜 작업은 이제 시작일 뿐임
그나마 다행인 건 서버 쪽 JS 커뮤니티가 어떤 이유에서인지 이미 잦은 깨짐에 익숙하다는 점임
내가 쓰는 런타임에 한 사람도 들여다보지 않은 코드가 들어간다는 생각은 불편함
하지만 이게 큰 문제 없이 실제로 동작한다면 꽤 놀라운 일임
이 결정들을 LLM이 했는지는 모르겠지만, Claude는 문제의 올바른 해법을 찾기보다 테스트를 수정하는 식의 수상한 행동을 더 잘 하는 경향이 있다고 항상 느꼈음
GPT/Codex는 이 점에서는 더 정직함
곧바로 안정 릴리스가 될 것 같지는 않지만, 틀렸다는 게 증명되면 기쁘겠음
이 리라이트 전체에 회의적이고, Jarred Sumner는 인터넷 팔로워가 엄청나서 광고처럼 느껴짐
Hacker News 의견들
발표에서 리라이트가 1주일 걸렸다고 하면, Zig 관용구를 Rust 관용구로 매핑하는 이 매우 상세한 지침 파일을 준비하는 데는 시간이 얼마나 들어갔는지 궁금해짐: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...
게다가
Pointers & ownership와Collections섹션을 보면 Bun 코드베이스는 이미 내부 스마트 포인터 타입을 써서 Rust 대응물과 1:1로 매핑되도록 준비돼 있었고,bun_collectionsRust 크레이트도 이미 존재함이 리라이트는 오래전부터 준비돼 있었고 Anthropic 인수 협상 중 Bun 팀이 제안한 것처럼 보임
걸린 돈이 너무 크니 커뮤니티에 마케팅 알바를 심을 유인이 분명하고, 일부는 그냥 진영 논리에 빠져 있음
Anthropic이 Bun을 소유한 이상, 이 작업이 실제보다 쉬워 보이게 만들 유인도 충분함
출력 규모가 워낙 커서 여기에는 곱셈 효과가 있어 보임
다만 이 규칙을 만들기 위해 얼마나 많은 암묵지가 필요했는지, 이 파일을 얼마나 반복 개선했는지도 궁금함
예를 들어 이 규칙 중 얼마나 많은 것이 번역 반복 과정에서 만난 실패 사례에서 나온 것인지 알고 싶음
using internal smart pointer types that map 1-to-1 to Rust equivalents라고 했지만, 스마트 포인터는 Rust가 발명한 게 아님포인터가 있는 다른 언어로 코드를 짜면 이미 머릿속으로 같은 타입들을 모델링하고 있음
그리고
bun_collectionsRust 크레이트가 이미 있었다는 건 틀렸음코드베이스의 PR 일부일 뿐이고, 이전부터 존재한 게 아님
의심을 덜고 IPO 분위기를 더 띄우는 건 아주 쉬울 텐데, AI를 몰아가기 위해 필요했던 숨은 작업을 별도 저장소로 공개하고 모두가 결과를 재현하게 하면 됨
결국 고객들이 이루려는 것도 “7일” 만에 쓸 수 있는 코드 100만 줄 아닌가
모두가 자기 워크플로에 재현해 보면서 Anthropic 사용량 지표도 올라갈 것임
정말 멋진 결과였다면 링크와 지침이 달린 블로그 글부터 냈을 것 같음
지금 이 순간 블로그 글이 작성 중이라 내가 틀렸음이 증명될 수도 있긴 함
그게 음모론의 핵심인가
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은 JavaScriptCore를 JS 엔진으로 사용하므로 Bun 자체는 JavaScript 파싱, 해석, JIT를 하지 않거나 적어도 하지 않아야 함
수정: 잘못 읽었음. “JavaScript interpreter wrapper”라고 했으니 맞는 표현임
+때문인지 다른 요인도 있는지는 모르겠지만, 모바일에서는 줄 수 변경량에 밑줄이 생기고 탭하면 전화를 걸 수 있음diff 크기 때문에 그런 거라면 꽤 웃김
리라이트 결과가 비슷한 LOC로 나오는 건 이상한 일이 아님
$ 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줄임
Zig에서 안전하지 않은 코드는 어떻게 검색함?
아니면 그냥 어디에나 있다고 가정해야 하나
unsafe키워드가 들어간다면 좋은 리라이트처럼 보이지 않음코드의 절반 가까이가 여전히 unsafe라면 Rust로 리라이트하는 의미가 뭔가
집에 있는 것:
10428아직 이 내용을 다룬 블로그 글을 쓰는 중이고, 더 자세히 공유할 예정임
배경이 궁금하면 Bun v1.3.14와 그 이전 릴리스 노트의 버그 수정 목록을 훑어보면 됨
Rust가 이 전부를 잡아주진 않음. 참조를 너무 오래 잡고 있어서 생기는 누수나 JS 경계를 넘어 재진입하는 모든 문제는 여전히 우리가 책임져야 함
하지만 그 목록의 상당수는 use-after-free, double-free, 오류 경로에서 해제를 잊는 문제이고, 이런 것들은 컴파일 오류가 되거나 자동 정리로 바뀜
I work on Bun and this is my branchThis 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 바이너리를 폭넓은 실제 애플리케이션에서 나란히 돌리거나, 가능하면 프로덕션에서 섀도 실행할 계획이 있는지 궁금함
대략적인 추정치를 줄 수 있나
이 릴리스를 사용자 워크플로를 깨지 않게 내보내기 위한 구체적인 계획도 있는지 알고 싶음
약 9일 전에 Jarred는 이게 병합될지 전혀 확실하지 않고 과잉반응이라고 썼음
아이러니함
Linus가 Linux 커널을 리라이트하지 않겠다고 말해놓고 어느 날 일어나 전체를 기계 보조 Rust 리라이트로 병합했다면 어떤 난리가 났을지 상상해보라
쓴 토큰 비용을 정당화해야 할 게 뻔했음
와, 앞으로 지켜보는 재미가 있겠음
이 코드가 검토됐을 가능성은 전혀 없지만, 어쩌면 이제는 모델이 코드를 쓰고 검토하는 걸 믿을 수 있는 포스트 휴먼 시대에 들어섰는지도 모름
이건 Gastown 같지만 훨씬 더 유명한 프로젝트에서 벌어진 일임
앞으로 이 프로젝트가 새 기능을 어떻게 추가할 수 있을지, 아니면 추가 자체가 가능할지 흥미로움
Anthropic이 Bun을 정확히 어떻게 쓰는지 아는 사람 있나?
Claude Code의 일부인가?
앞으로 Bun을 쓰는 게 꽤 걱정되는데, 그 걱정이 Claude 사용에도 어느 정도 적용되는지는 잘 모르겠음
자동 언어 번역을 잡아낼 테스트 스위트를 믿을 수 없다면, 애초에 그 테스트 스위트를 전혀 믿으면 안 됨 :)
자동 번역을 실험하는 건 사실 기대되지만, 하위 호환성 문제가 많이 생길까 봐 걱정됨
커밋을 보기 시작했는데, 기본적으로 “테스트가 통과하지 않음” 문제를 테스트 자체를 바꾸는 식으로 해결하고 있음
이미 배포된 프로그램에서 제대로 동작하게 만드는 진짜 작업은 이제 시작일 뿐임
그나마 다행인 건 서버 쪽 JS 커뮤니티가 어떤 이유에서인지 이미 잦은 깨짐에 익숙하다는 점임
하지만 이게 큰 문제 없이 실제로 동작한다면 꽤 놀라운 일임
GPT/Codex는 이 점에서는 더 정직함
이 리라이트 전체에 회의적이고, Jarred Sumner는 인터넷 팔로워가 엄청나서 광고처럼 느껴짐
훌륭함! 테스트에 임의로
sleep(1)만 추가하면 됨. 걱정하지 마, 다 잘될 거야!Bun을 쓰는 내 몇 안 되는 프로젝트는 다른 것으로 옮길 예정임
이런 무모한 변경을 허용하는 거버넌스는 신뢰하지 않음
애초에 잘 작성됐기 때문에 리라이트할 필요도 없음
한편으로는 불의 세례가 어떻게 될지 지켜보는 건 흥미롭겠고, 장기적으로는 결국 문제들이 해결될 것 같긴 함
교육용으로 볼 만한 스레드가 있음. 일주일 전 Jarred가 다시 병합 결정에서 비켜나가고, 수많은 보병들이 곧 병합될 거라고 예측한 사람들을 공격했던 스레드임:
https://news.ycombinator.com/item?id=48073680
지금 보니 잘 버티지 못한 말이었지?
이게 조금이라도 잘못되면, 자기 물건에 취한 마약상이라는 조롱이 끝도 없고 암울하게 이어질 것임
Mythos 논문 읽어봤나? 의인화가 정말 심함
그냥 싸구려 관심 끌기일 수도 있지만, 정말로 LLM이 의식이 있다고 믿는다면… 와우