Mold 링커 3.0.0 출시 및 Rust 재작성 관련 논의

공동 유지보수하는 Linux 배포판에서는 mold를 부트스트랩 링커로 사용해 Rust 자체를 빌드하며, 버전을 하나씩 올려 빌드하는 긴 과정에서 몇 시간이나 절약했음. mold가 C로 작성되어 있어 아주 이른 단계에 빌드한 뒤 배포판 전체의 기본 링커로 쓰면서 곳곳에서 빌드 속도를 높일 수 있었음. 이제는 안타깝게도 C 버전을 포크해 mold2로 영원히 유지보수해야 할 처지임. Rust가 모든 문제에 적합한 도구는 아님.

Rust 링크에 LLD를 쓰지 않는 이유가 무엇인가? Rust를 빌드하려면 어차피 LLVM이 필요하므로 의존성이 추가되지도 않음.

그건 본인의 선택이자 책임. 적어도 비용을 지불하지 않으면서 업스트림을 구속할 수는 없음. mold가 C로 작성됐다는 사실을 유용하게 활용하는 부트스트랩 체인을 만들었다는 이유만으로 Rust가 나쁜 해법이라고 할 수는 없음.

필요성이 충분히 타당하다면 #[no_mangle]과 extern C 지원을 요청해 볼 만하지 않을까? 막 출시된 시점이기도 함. 그게 원인인지, 아니면 어떤 의존성이 문제인지 궁금함.

언어를 바꿔 유지보수 부담을 줄이려는 결정이 왜 여기서 Rust가 잘못된 도구라는 뜻이 되는지 이해하기 어려움. 가용 자원을 고려하면, 안심하고 동시성 코드를 작성할 수 있다는 점은 이 작업에 큰 이점으로 보임.

몇 달짜리 재작성일 줄 알았는데 3주라니 놀라움. 이제 에이전트 시대라는 걸 잠시 잊고 있었음.
수정: 첫 커밋이 올라왔을 때는 이미 한동안 작업을 진행해 온 것으로 보임.

이제 mold와 Wild의 차이는 무엇인가? Wild는 다른 자료구조를 사용하는지 궁금함. Wild는 Linux만 지원하는 또 다른 고속 링커임.

Wild의 주목적은 증분 링크임. 이제는 두 프로젝트의 경쟁과 프로젝트별 미묘한 성능 차이가 주된 차별점일 듯함.

Zig는 여러 면에서 더 나은 C라서 Mold를 재작성하기에 딱 맞는 언어라고 생각했음.

Zig에서는 안전성과 속도 중 하나를 선택해야 하지만, Rust에서는 대체로 둘 다 얻을 수 있음.

재작성을 선택한 동기가 궁금함. 손상된 입력에 대한 경계 검사가 한 가지 이유일 듯하지만, C/C++ 코드에서 손상된 입력 처리를 고치는 것도 그리 어렵지 않고 오히려 수고가 덜 들 것 같음. 그런데도 재작성을 택한 이유는 무엇인가?
그리고 재작성에 AI 도구를 사용했는지도 궁금함.

세계 최고의 프로그래머들이 50년 동안 시도하고도 실패한 일이므로, 손상된 입력 처리를 고치는 게 그리 어렵지 않다는 데 동의하기 어려움.
현재 Rust의 주요 단점은 일부 비주류 플랫폼을 지원하지 않는다는 점인데, 어차피 mold도 그런 플랫폼은 지원하지 않으므로 여기서는 문제가 되지 않음.

C와 C++을 한데 묶는 관행은 고무보트와 항공모함을 같은 범주로 묶는 것처럼 우습고 비생산적임.

아주 기초적인 이해로는 mold의 속도를 높이는 요소 중 하나가 동시성인데, C/C++에서는 오류가 발생하기 훨씬 쉬울 듯함. 데이터 경쟁을 걱정하지 않아도 된다면, 작업을 더 복잡하게 분할해 속도를 높이는 기법을 한층 자신 있게 시도할 수 있을 것 같음.

C나 C++로 안전한 코드를 작성하는 건 가능하지만, 기존 코드를 읽고 안전성을 입증하려면 처음 작성할 때만큼의 노력이 필요할 정도로 어려움. 지난달에 직접 작성했더라도 주변 코드가 바뀌었다면 마찬가지임. 개발자는 매번 옳아야 하지만, 공격자는 단 한 번의 실수만 있으면 됨.

안심하고 동시성 코드를 작성할 수 있다는 점도 동기일 듯함. 병렬성을 더 끌어내면 성능을 높일 수 있지만, 빌림 검사 없이 세밀한 병렬 처리를 올바르게 구현하기는 어려움.

이제 Rust™로 재작성했다는 게 새로운 홍보 문구가 됨.

AI가 대충 생성한 링커는 원하지 않음. 왜 자기 프로젝트를 팔아넘기는 것인가?

이건 AI가 대충 생성한 링커가 아님. Mold는 링커 분야에서 기준이 되는 프로젝트이며, 이번 이식도 공식 작업임.