Reescrita do mold em Rust quer ser o linker padrão do Linux

Rui Ueyama está reescrevendo o mold de C++ para Rust. O mold é um dos linkers mais rápidos disponíveis no Linux. O Phoronix noticiou em 11 de setembro de 2026 que essa reescrita é o centro da futura série 3.x. O segundo objetivo é o que os desenvolvedores devem acompanhar: o mold quer que as distribuições Linux o instalem como /usr/bin/ld, o linker padrão que toda compilação utiliza.

Um linker é a última etapa de uma compilação. O compilador transforma cada arquivo-fonte em um arquivo-objeto. O linker então costura esses objetos e suas bibliotecas em um único programa executável. Em um projeto grande de C++ ou Rust, essa etapa final costuma decidir quanto tempo você espera.

A diferença é grande. O Phoronix a descreveu em termos concretos. Um trabalho de ligação que o mold conclui em "algumas centenas de milissegundos" pode levar "vários segundos, dezenas de segundos ou até minutos com o linker padrão".

O repositório do mold afirma que ele faz a ligação 4,9 vezes mais rápido que o lld do LLVM na mediana, e 1,9 vez mais rápido que o wild. Ueyama também escreveu o lld, ou seja, ele compete com o próprio trabalho anterior. O projeto está em uso em produção desde 2021. Ele suporta 14 arquiteturas de processador, entre elas x86-64, ARM, RISC-V, PowerPC, s390x, LoongArch e SPARC64.

Por que Rust, e por que agora

Ueyama apresentou suas razões em uma discussão fixada no repositório do mold no GitHub, iniciada em 1º de setembro de 2026. A segurança de memória veio em primeiro lugar. Um linker lê arquivos-objeto que não criou e faz muita aritmética de ponteiros. É exatamente aí que um erro de memória é fácil de escrever e demorado de encontrar.

Ele também apontou as ferramentas. O Rust traz o Cargo para gerenciar dependências e simplifica a compilação cruzada. As duas coisas importam para uma ferramenta que precisa ser compilada para 14 arquiteturas. O C++20, linguagem atual do mold, não lhe oferece nenhuma das duas por padrão.

O argumento do momento é o que vai gerar discussão. Ueyama credita às ferramentas de programação com IA o fato de a reescrita ter se tornado viável. "A reescrita assistida por IA mudou drasticamente o custo desse tipo de trabalho", escreveu ele. "Eu provavelmente não teria tentado isso no ano passado, mas hoje exige surpreendentemente pouco esforço."

Ele definiu a escolha como uma aposta de longo prazo: "esta decisão fará mais sentido em retrospecto daqui a 10 ou 20 anos do que pode parecer hoje".

Outros projetos seguiram o mesmo caminho neste ano. O Bun 1.4 levou sua reescrita em Rust para produção, e o YSERVER 1.5, um servidor X11 escrito do zero em Rust, teve seu código inicial escrito com ajuda de IA.

Virar /usr/bin/ld é a metade mais difícil

Não é a velocidade que impede um linker de se tornar o padrão. É a compatibilidade. O GNU ld e seu irmão mais rápido, o gold, acumulam décadas de comportamentos dos quais os scripts de compilação dependem silenciosamente. Isso vai da sintaxe dos scripts de ligação a opções obscuras de linha de comando.

O projeto sabe disso. "Um dos principais objetivos da série mold 3.x é tornar o mold adequado para adoção como /usr/bin/ld pelas distribuições Linux", noticiou o Phoronix. O plano após a reescrita é lento e colaborativo: "Em seguida, conduziremos testes de compatibilidade extensos e trabalharemos de perto com os desenvolvedores das distribuições Linux."

Etapa	Situação
Reescrever o mold de C++ para Rust	Em andamento, com foco na série 3.x
Testes de compatibilidade extensos	Planejados, após a reescrita
Coordenação com desenvolvedores das distribuições	Planejada, após os testes
Entrega como /usr/bin/ld por padrão	Sem data

Nenhuma distribuição se comprometeu com a mudança. Nenhuma data foi dada para qualquer uma dessas etapas.

O que isso significa para os desenvolvedores

Nada quebra hoje. O mold 2.x continua como está, e a reescrita em Rust chega numa futura série 3.x que não tem data de lançamento.

Se você nunca experimentou o mold, esta é uma boa semana para medir o que ele economizaria. Em uma cadeia de ferramentas Linux, você pode apontar uma única compilação para ele com -fuse-ld=mold. Depois compare a etapa de ligação com o seu padrão atual. Projetos com muitos arquivos-objeto e bibliotecas estáticas grandes veem a maior diferença; um projeto pequeno pode não ver nenhuma.

Se você mantém um sistema de compilação ou um pacote de distribuição, a fase de compatibilidade é onde a sua contribuição conta. Scripts de ligação personalizados, opções incomuns e ajustes de otimização em tempo de ligação são as partes com maior chance de divergir. Ueyama disse explicitamente que quer os desenvolvedores das distribuições envolvidos antes de qualquer mudança de padrão.

Há aqui um segundo ponto digno de nota, separado dos linkers. O mantenedor de uma ferramenta de sistema amplamente usada afirmou publicamente que a ajuda da IA mudou qual reescrita ele estava disposto a tentar. Se esse julgamento se sustenta é uma pergunta que a série 3.x vai responder em código. Vale conferir pelo resultado, não pela afirmação.