Bun Rust 재작성: "코드베이스가 기본적인 miri 검사에 실패하고 safe Rust에서 UB를 허용"

핵심 요약

이 이슈는 현재 상태이며, 대화는 topic으로 잠기고 collaborator로 제한됐고, 관련 수정으로 #30728과 #30876이 연결돼 있음제보자는 ::init으로 만든 값이 원본 Box가 drop된 뒤에도 ()를 호출할 수 있어, Mi… [영문·코드 생략] 재작성: "코드베이스가 기본적인 검사에 실패하고 Rust에서 UB를 허용" ( [영문·코드 생략] 1P [영문·코드 생략] ⁺ 8일전 | ★ | 댓글 1개 이 이슈는 현재 상태이며, 대화는 topic으로 잠기고 collaborator로 제한됐고, 관련 수정으로 #30728과 #30876이 연결돼 있음 제보자는 ::init으로 만든 값이 원본 Box가 drop된 뒤에도 ()를 호출할 수 있어, Miri가 [영문·코드 생략] 기반 Behavior를 보고한다고 제시함 재현 코드는 [영문·코드 생략] *b" [영문·코드 생략] ")로 만든 버퍼를 [영문·코드 생략] &* )에 넘긴 뒤 [영문·코드 생략] 후 [영문·코드 생략] 를 호출하는 형태였고, Miri는 [영문·코드 생략] from_raw_parts 지점에서 오류를 냄 robobun은 문제가 재현됐다고 확인하며, ::init이 함수인데도 lifetime을 지워서 &[u8]를 만들 수 있다고 정리함 연결된 #30728은 ::init과 dir_iterator:: ()의 병렬 구멍을 fn으로 바꾸고, 호출부 약 70곳에 allocation을 명시한 주석을 추가하는 방향임 같은 수정에는 세 시그니처에서 키워드가 필요함을 강제하는 compile_fail doctest와 resolver의 [영문·코드 생략] 수정도 포함됐다고 설명됨 AwesomeQubic은 추가로 ::init이 provenance를 지우며 =- [영문·코드 생략] provenance에서도 실패

기술적 내용

한다고 덧붙임 JavaDerg는 init이 &[u8]의 암묵적 lifetime을 받아 작업으로 이를 지운 뒤 'static처럼 보이는 Self를 반환해 [영문·코드 생략] free와 aliasing을 허용한다고 설명함 JavaDerg는 Rust의 안전 모델 위에서 UB가 예상 밖의 위치에서 문제를 일으킬 수 있다며, 사용 전반에 대한 검토가 필요하고 다른 언어의 메모리 관리 방식을 Rust로 1:1 번역하는 것은 적합하지 않다고 경고함 robobun은 관련 커밋으로 [영문·코드 생략] 테스트와 dir_iterator: [영문·코드 생략] ; [영문·코드 생략] sites를 추가함 SimonReiff는 저장소의 파일에서 주석을 제외한 [영문·코드 생략] 결과가 13255줄이라고 제시하며, 즉시 되돌리고 AI 코드 사용 정책과 절차를 논의해야 한다고 요구함 -Sumner는 port가 현재 원래 코드에 가능한 한 가까운 1:1 mapping을 출발점으로 삼고 있으며 개선 중이라고 밝히고, 코드의 버그나 behavior를 계속 새 이슈로 제보해 달라고 요청함 함께 보면 좋은 글 Bun의 재작성 PR이 머지됨 Bun의 실험적 재작성판이 x64 glibc에서 99.8% 테스트 호환성에 도달 Bun의 재작성에 대한 내 생각 2.0은 재작성으로 인해 Bun에서 분리될 예정 Rust로 게임 개발을 한 3년 후에 떠나며 인증 이메일 클릭후 다시 체크박스를 눌러주세요 ▲GN⁺ 8일전 [-] [영문·코드 생략] 의견들 처음 Bun에 관심을 가진 건 Zig로 작성됐기 때문이고, Zig에 끌린 건 Kelley의 의사결정과 취향을 신뢰했기 때문임 이후 Bun에 더 흥미를 느낀 이유들도 결국 내가 존중할 만한 선택들이었기 때문인데, 인수 후에도 조심스럽게 낙관하려 했음 하지만 이번 행보

실무적 시사점

는 신뢰하기 어려운 의사결정으로 보이며, 자체가 문제가 아니라 Anthropic이 Bun을 이런 식으로 관리한다면 도구함의 신뢰할 만한 구성요소로 더는 베팅하기 어렵다는 느낌임 코드만이 아니라 그 뒤의 사고방식까지 신뢰해야 하는데, 지금은 내부 전용 도구처럼 보임 Bun은 정말 흥미로운 프로젝트지만 이슈에 올라오는 세그멘테이션 폴트 수가 진지한 운영 환경에 쓰기엔 너무 걱정스러웠음 이번 방향이 그걸 고치는 한 방법일 수는 있으니 지켜볼 일임 이해는 되지만, 내 출발점은 꽤 다름 오래된 팬으로서 Bun은 덜 야심 찬 Deno처럼 보였고, Zig를 배우고 싶지 않아 취미로라도 자체를 건드릴 가능성이 낮았음 그런데 지난 몇 년간 런타임에 덜 묶인 방식으로 꽤 큰 코드베이스를 유지하려다 보니 Bun에 점점 마음이 열렸고, 특정 런타임을 요구사항으로 만들고 싶지 않았지만 Bun은 Deno처럼 , , S3, 웹소켓, 로컬 비밀 저장소, 번들링, 컴파일, 빠른 속도 같은 이유를 계속 제공했음 지금은 여러 서버와 프런트엔드 앱 서버를 [영문·코드 생략] 단일 실행 파일로 만들어 거의 어디서나 실행·배포하고 있음 다만 이런 방식이 흔하다고 보진 않고, 이번 기반 포팅이 실패하면 관련 결정들을 모두 후회하기 딱 좋은 위치에 있음 그래도 실패하지 않는다면 흥미로움. LLM으로 무엇이 가능한지 보여주는 사례가 되고, 앞으로 Bun이 Rust로 개발되는 건 내 기준에선 장점임 반대로 실패해도 정보로서 중요함. Bun은 주요 [영문·코드 생략] 런타임 중 하나이고, Anthropic에는 엄청난 자원과 최신 모델 접근권, 사실상 무제한 예산이 있으니 이들이 못 한다면 아직은 정말 불가능하다는 뜻에 가까움 Bun이 Deno보다 끌렸던 이유가 궁금함 Zig를 안전하지 않은 Rust로 옮길

향후 전망

거였다면 왜 번역 도구를 만들지 않았는지 이해가 안 됨 언어 구조를 일대일로 매핑하고 코드베이스의 패턴을 하드코딩하면 결정적인 변환을 얻을 수 있었을 텐데, 친구 말처럼 “ [영문·코드 생략] c를 c2rust에 연결”하는 식도 가능했을 것임 지금 결과물은 입력보다도 덜 신뢰됨. 입력은 메모리 안전하진 않았지만 사람이 직접 쓴 코드였고, 출력은 메모리 안전하지 않은 데다 바이브 코딩됐고 사람이 제대로 본 적도 없어 보임 이런 용도에 에이전트형 AI를 남용하는 의미가 뭔지 모르겠음 c2rust 결과물을 본 적이 있다면 그렇게 말하기 어려움 C의 안전하지 않은 포인터 의미론을 Rust의 안전하지 않은 함수 라이브러리로 흉내 내는 식이라 결과가 끔찍함 몇 년 전 버그를 보던 중 누군가 c2rust로 변환해 봤는데, 변환된 안전하지 않은 Rust도 C 코드와 같은 지점에서 세그멘테이션 폴트를 냈음 호환은 되지만 안전하진 않음 핵심은 문자열 조작을 C나 안전하지 않은 Rust로 하지 말라는 것임. 작업에 전혀 맞지 않는 도구임 그들은 만들었음. 아주 동적인 번역 도구를 “ [영문·코드 생략] c를 c2rust에 연결하면 된다”는 건 생각처럼 작동하지 않음 이런 도구들은 오류가 많고 코드를 매우 장황하고 추론하기 어렵게 만듦 작은 앱에는 통할 수 있지만 전체 재작성에는 맞지 않음 나도 다른 스레드에서 거의 같은 얘기를 했지만, 소프트웨어 작성 방식에 대해서는 조금 다른 관점임 Zig를 Rust로 번역하는 것보다, 정적 Python으로 파서를 작성한 뒤 각 언어에 맞는 관용적 구조로 Zig와 Rust로 낮추는 편이 더 낫다고 봄 이를 위해 이런 목적에 맞는 방언 파서를 만들었고, 대부분의 코드와 호환성을 유지하면서 번역을 쉽게 해 주는 [영문·코드 생략] 기능 일부를.

원문: https://news.hada.io/topic?id=29566