De todos los pasos que hay entre el código y un programa que funciona, el último es el que menos atención recibe y el que más suele hacer esperar. El compilador traduce cada archivo por separado, y después el enlazador tiene que coser todas esas piezas —más las bibliotecas— en un único ejecutable: resolver cada símbolo, colocar cada sección, ajustar cada dirección. Es un trabajo que no se puede repartir fácilmente y que hay que rehacer entero cada vez que cambias una línea.
En proyectos grandes eso se nota. Enlazar un navegador o una biblioteca de aprendizaje automático con el enlazador clásico de GNU puede llevar decenas de segundos, cada vez, al final de cada compilación. Ese es el hueco que vino a ocupar mold, que escribió Rui Ueyama partiendo de cero. No es un recién llegado al asunto: Ueyama es el autor original de lld, el enlazador de LLVM, y empezó mold precisamente porque se topó con límites de diseño que ya no podía arreglar optimizando aquel.
El resultado es, con diferencia, el enlazador más rápido que hay para Linux. Y aun así, la inmensa mayoría de las distribuciones siguen trayendo GNU ld como /usr/bin/ld. «Me parece una situación desafortunada para la comunidad de Linux», dijo Ueyama en septiembre, asumiendo parte de la responsabilidad.
El 5 de octubre de 2026 publicó la versión con la que pretende cambiarlo. Y lo primero que ha hecho ha sido tirar el código y volver a escribirlo.
mold 3.0 es la primera versión escrita en Rust. La 2.42.1, del 11 de septiembre, fue la última del código en C++. No es una bifurcación ni un experimento paralelo: es la rama principal, y se presenta como sustituto directo de la anterior. Mismas opciones de línea de órdenes, mismas arquitecturas, misma salida salvo las correcciones de errores, y —esto es lo que no era evidente— la misma velocidad: «el rendimiento al enlazar sigue a la par con 2.42.1», dicen las notas de la versión.
Lo interesante es que la reescritura no es el objetivo. Es el medio.
Claves de mold 3.0
- Escrito entero en Rust. Requiere Rust 1.95 o posterior y un compilador de C. Se construye con Cargo en vez de CMake.
- Una dependencia menos. Ya no necesita oneTBB, la biblioteca de paralelismo de Intel; el paralelismo lo resuelve ahora con las herramientas del propio Rust. Sigue enlazando estáticamente mimalloc 3.5.3 como reservador de memoria.
- Sustituto directo de la 2.42.1. Acepta las mismas opciones y produce la misma salida. El equipo pasó la batería de pruebas en todas las arquitecturas soportadas y no encontró regresiones.
- Sin coste en velocidad. El rendimiento se mantiene igual que en la última versión en C++, que es lo que había que demostrar: una reescritura que fuera más lenta no habría servido de nada.
- El objetivo de la serie 3.x es cerrar lo que falta para ser compatible con GNU ld, y muy en concreto el soporte de linker scripts.
- Licencia MIT, como la 2.x.
Las cifras
De la tabla de pruebas del propio proyecto, medida en 2026 sobre un Threadripper 7980X y en compilación de depuración, que es el caso que de verdad importa porque es el que repites cien veces al día:
| Programa | mold | lld | |
|---|---|---|---|
| Blender | 0,86 s | 4,72 s | 5,5× |
| Chromium | 1,65 s | 16,64 s | 10,1× |
| TensorFlow | 3,15 s | 50,73 s | 16,1× |
Y conviene leer bien contra quién se compara: lld, el enlazador de LLVM, que ya es bastante más rápido que GNU ld. Los cincuenta segundos de TensorFlow son con el rival bueno.
Por qué importa
Lo primero es lo evidente: medio minuto de espera al final de cada compilación no es solo tiempo perdido, es tiempo en el que te vas a otra cosa y pierdes el hilo. Un ciclo de tres segundos y uno de cincuenta producen formas distintas de trabajar.
Pero lo segundo es más importante, y es el motivo real de esta versión. Casi nadie cambia su enlazador. Hay que saber que existe la alternativa, saber que se puede cambiar y saber cómo; la mayoría de la gente que compila software en Linux usa lo que venga puesto. Por eso Ueyama no quiere que mold sea una opción que instalas: quiere que sea /usr/bin/ld.
Y ahí está el obstáculo técnico que explica todo lo demás. Para ser el enlazador del sistema no basta con enlazar programas de usuario: hay que poder enlazar también el núcleo, los cargadores de arranque y el software empotrado, y todo eso depende de los linker scripts, unos archivos que describen al detalle cómo colocar cada sección en memoria. GNU ld los soporta por completo. mold, todavía no del todo. Cerrar esa distancia es, literalmente, el propósito declarado de la serie 3.x.
¿Y por qué reescribirlo en Rust justo ahora, antes de esa tarea? Ueyama lo atribuye a las garantías de seguridad del lenguaje y a otras comodidades que le resultan útiles como desarrollador principal. Dicho de otro modo: no es un cambio pensado para el usuario, sino para quien tiene por delante años de mantener y extender un programa muy concurrente y muy manipulador de memoria.
Rust ya está en los cimientos de Linux
mold no es un caso aislado. Es una pieza más de un movimiento que lleva un tiempo ocurriendo por debajo, y que este último año ha dejado de ser una promesa.
En el núcleo. El 12 de diciembre de 2025, Miguel Ojeda envió a la lista del kernel un parche con un título que lo resume: «rust: conclude the Rust experiment». No añadía ninguna funcionalidad; quitaba dieciocho líneas de documentación, las que avisaban de que el soporte de Rust era experimental y que ningún controlador en Rust servía para producción. «En la cumbre de mantenedores de 2025 el experimento acaba de darse por concluido», explicaba el mensaje. «El experimento ha terminado, es decir: Rust se queda.»
No es una declaración simbólica. Hay controladores en Rust funcionando y en la lista del propio proyecto Rust for Linux: el Binder de Android —que va en millones de teléfonos—, el controlador de GPU Nova para hardware de NVIDIA, Tyr para las GPU Mali de Arm, el controlador de dispositivo de bloques nulo, y controladores de red PHY.
En el espacio de usuario. Ubuntu 25.10 fue la primera versión que puso por omisión uutils, la reimplementación en Rust de las utilidades básicas —ls, cat, cp y compañía—, junto con sudo-rs en lugar del sudo de toda la vida. En la 26.04 LTS la transición se frenó a propósito: cp, mv y rm se quedaron en sus versiones GNU porque una auditoría externa encontró problemas de tipo TOCTOU en las implementaciones nuevas. Esos tres son los que faltan, y Ubuntu 26.10 —que sale el 15 de octubre— está previsto que complete el cambio.
Ese episodio merece subrayarse, porque es el contrapeso honesto de toda esta historia: escribir algo en Rust no lo hace correcto. Evita una familia concreta de errores, la de memoria; no evita que una comprobación se haga en el momento equivocado.
En las herramientas. mold tampoco es el único enlazador nuevo en Rust. wild, de David Lattimore, persigue un objetivo distinto: ser rápido en el desarrollo iterativo, y a la larga hacer enlazado incremental, rehacer solo la parte que cambió en vez del ejecutable entero. Eso último todavía no está implementado, según su propia documentación, y aun así ya es lo bastante rápido como para que las pruebas de mold lo incluyan entre los rivales a los que medirse. El proyecto lo respalda el Rust Innovation Lab de la Fundación Rust.
Lo que esto no es
Tres precisiones, porque este tipo de noticias se cuenta mal con facilidad.
mold 3.0 todavía no enlaza el kernel de Linux. Poder hacerlo es el objetivo de la serie 3.x, no algo que esta versión traiga ya resuelto. Lo que se ha publicado es la misma funcionalidad de antes, sobre una base nueva.
No hace tus programas más seguros. Un fallo de memoria en un enlazador produce un binario roto o un enlazador que se cae, no una vulnerabilidad en el programa que estás compilando. El beneficio de Rust aquí es para quien mantiene mold, no para quien lo usa.
Ninguna distribución ha anunciado el cambio. Que mold aspire a ser el enlazador por omisión no significa que vaya a serlo. Eso se decide distribución por distribución, y pasa por convencer a gente que tiene buenas razones para ser conservadora con una pieza de la que depende absolutamente todo lo demás.
Con esas tres salvedades, lo que queda sigue siendo notable. Un programa de sistema, de los de verdad, de los que están debajo de todo lo demás, ha cambiado de lenguaje sin perder un ápice de rendimiento y sin que sus usuarios tengan que tocar nada. Hace cinco años ese era el argumento que se usaba para decir que no se podía hacer.
Más referencias sobre Rust en Linux:
«rust: conclude the Rust experiment», de Miguel Ojeda (LKML, 12 de diciembre de 2025) ·
Rust for Linux, con la lista de controladores en el núcleo ·
Phoronix sobre el fin del experimento ·
documentación de sudo-rs en Ubuntu ·
OMG! Ubuntu sobre el final de la transición a uutils ·
wild, el otro enlazador en Rust ·
Phoronix sobre el anuncio de la reescritura.
Fuente: notas de la versión mold 3.0.0 (5 de octubre de 2026) y el repositorio de mold, de donde salen las cifras de las pruebas.