Canonical apuesta por reemplazar millones de líneas de C con Rust usando inteligencia artificial

Canonical ha puesto sobre la mesa una de las preguntas más importantes para el futuro de Linux: ¿podemos migrar grandes bases de código escritas en C hacia Rust sin romper sistemas críticos? La empresa detrás de Ubuntu está financiando una investigación doctoral de tres años junto con la Universidad de Bristol para explorar si repositorios maduros de C pueden convertirse en Rust seguro, correcto y mantenible.

El matiz es importante: no se trata de que Canonical ya esté reemplazando automáticamente millones de líneas de C en Ubuntu. El anuncio confirmado habla de una plataforma capaz de traducir repositorios de cientos de miles de líneas de C a Rust, con apoyo equivalente de UK Research and Innovation, y con una arquitectura que combina modelos de lenguaje, análisis de programas, pruebas, métodos formales y reparación automática.

1. Qué anunció realmente Canonical

Jon Seager, vicepresidente de ingeniería de Canonical, explicó que la empresa financia un PhD de tres años con soporte equivalente de UK Research and Innovation. El proyecto será liderado en Bristol por el profesor Meng Wang, con la supervisión de Dr. Cristina David y el propio Seager. Su objetivo es construir una plataforma de extremo a extremo capaz de traducir repositorios grandes de C hacia Rust seguro, conductualmente correcto y mantenible.

El proyecto parte de una realidad incómoda: gran parte del software de sistemas que sostiene Linux, Ubuntu y muchas herramientas críticas sigue escrito en C. Reescribirlo manualmente es caro, riesgoso y lento, porque esos repositorios acumulan años de correcciones, compatibilidad, rendimiento y conocimiento operacional.

2. Por qué Canonical mira hacia Rust

Rust se ha convertido en uno de los lenguajes más atractivos para software de sistemas porque permite control fino sobre rendimiento y recursos, pero reduce muchas clases de errores de memoria que históricamente han afectado a C y C++. Canonical ya venía reforzando esta dirección: en marzo de 2026 se unió a la Rust Foundation como miembro Gold y señaló que Rust está ganando peso para construir sistemas resilientes en Ubuntu y más allá.

La propia Canonical afirmó que su trabajo con Rust empieza con proveer una toolchain actualizada en los repositorios de Ubuntu, pero se extiende hacia una experiencia de desarrollo de primera clase. También destacó que Ubuntu ya reemplazó componentes centrales como coreutils y sudo por implementaciones en Rust para reforzar la resiliencia del sistema operativo y de las plataformas cloud que dependen de él.

3. El problema: C sostiene el mundo, pero también arrastra riesgos

C sigue siendo esencial en sistemas operativos, controladores, librerías de bajo nivel, herramientas Unix, sistemas embebidos y componentes críticos. Su problema no es el rendimiento, sino la seguridad: errores como use-after-free, buffer overflow, double free, punteros colgantes y corrupción de memoria pueden convertirse en vulnerabilidades graves.

CISA y varias agencias aliadas han recomendado que los fabricantes de software desarrollen hojas de ruta hacia lenguajes con seguridad de memoria para reducir vulnerabilidades de diseño. Esa visión coincide con el interés de Canonical por avanzar hacia Rust en componentes sensibles, aunque de forma pragmática y verificable, no como reescritura masiva sin control.

4. Por qué no basta con “pedirle a la IA que traduzca”

El propio anuncio de Canonical advierte contra una lectura ingenua. Los traductores tradicionales pueden procesar mucho código, pero suelen conservar demasiado la estructura de C: el resultado puede compilar como Rust, pero depender de unsafe, mantener patrones incómodos de C y requerir mucho trabajo manual antes de que un mantenedor Rust quiera hacerse cargo.

Los modelos de lenguaje tienen el problema opuesto: pueden producir Rust aparentemente idiomático en ejemplos pequeños, pero sufren con el contexto de repositorios grandes. Seager lo resume con una idea central: una salida plausible no demuestra que el programa traducido se comporte igual que el original.

5. El enfoque neurosimbólico: IA más análisis formal

La investigación no se basa en un modelo de lenguaje actuando solo. Canonical describe una arquitectura neurosimbólica que combina aprendizaje automático con análisis convencional de programas, testing y métodos formales. La plataforma propuesta tiene cuatro partes principales: planificación, traducción, validación y depuración/reparación.

Repositorio C grande
  ↓
1. Scheduling
   Divide el repositorio en partes traducibles sin perder contexto.
  ↓
2. Translation
   Usa modelos entrenados o ajustados con conversiones C→Rust conocidas.
  ↓
3. Validation
   Verifica que Rust se comporte como el código C original.
  ↓
4. Debugging and repair
   Localiza diferencias y aplica correcciones dirigidas.
  ↓
Rust seguro, correcto y mantenible
  ↓
Revisión humana y evidencia antes de adopción

La pieza más importante es la validación. El proyecto explorará fuzz testing y enfoques formales de equivalencia para comprobar que la implementación Rust se comporta como la fuente en C. Cuando falle la validación, una etapa de depuración y reparación intentará localizar el defecto y corregirlo con técnicas de reparación simbólica.

6. La IA será una pieza, no el juez final

El mensaje más importante del anuncio es que el código generado debe tratarse como no confiable hasta que exista evidencia de que preserva el comportamiento deseado. Esa frase cambia la narrativa: la IA no reemplaza a compiladores, pruebas, fuzzing, revisión humana ni métodos formales. Los complementa.

7. AppArmor y snap-confine: pruebas difíciles, no ejemplos de juguete

Canonical eligió AppArmor y snap-confine como casos industriales de estudio. No son componentes simples. AppArmor forma parte del modelo de confinamiento y control de acceso de Ubuntu, mientras snap-confine participa en el aislamiento de aplicaciones snap. Canonical aclaró que esto no es un compromiso de reemplazar esas herramientas por el resultado generado, sino una forma de evaluar la técnica con software real y sensible.

Esa elección es relevante porque los proyectos de seguridad acumulan exactamente los problemas que dificultan la traducción: código de bajo nivel, rutas extrañas de error, compatibilidad histórica, interacción con el sistema operativo, comportamiento específico de plataformas, límites de privilegio y suposiciones que no siempre aparecen en una función aislada.

8. Por qué esto debe investigarse en una universidad

Canonical explica que automatizar migraciones no es solo “conectar un LLM a un compilador y repetir hasta que compile”. Hay preguntas profundas: cómo dividir un repositorio sin perder contexto semántico, cómo establecer equivalencia cuando C contiene comportamiento indefinido o dependiente de implementación, cómo manejar APIs con punteros, concurrencia, interfaces externas y límites del sistema operativo.

Estas preguntas cruzan lenguajes de programación, métodos formales, machine learning y software engineering. Por eso la colaboración con Bristol tiene sentido: permite usar casos prácticos de Ubuntu, pero abordarlos con rigor académico y no como una herramienta apresurada de conversión.

9. ¿Reemplazar millones de líneas de C?

El titular puede sonar a una sustitución inmediata de millones de líneas. La realidad es más prudente: Canonical está invirtiendo en una capacidad futura. InfoWorld reportó que el objetivo del proyecto es crear una plataforma para traducir cientos de miles de líneas de C a Rust, con AppArmor y snap-confine como estudios de caso, y recogió la misma advertencia: esto no implica reemplazar esos componentes por lo generado.

Aun así, la ambición sí apunta a un problema de escala. Si el método funciona en repositorios de cientos de miles de líneas, puede sentar las bases para migraciones mayores en el ecosistema Linux, especialmente en herramientas de seguridad, utilidades de sistema y componentes donde la memoria segura ofrece ventajas claras.

10. Qué puede ganar Ubuntu si el proyecto funciona

Si la investigación logra buenos resultados, Ubuntu podría beneficiarse en varias capas. Primero, en seguridad: menos exposición a errores de memoria en componentes nuevos o migrados. Segundo, en mantenimiento: traducciones más idiomáticas y aceptables para equipos Rust. Tercero, en gobernanza: capacidad de justificar migraciones con evidencia, no con entusiasmo.

11. Qué riesgos siguen abiertos

La investigación existe precisamente porque el problema no está resuelto. La traducción automática de C a Rust enfrenta riesgos técnicos muy difíciles: punteros, aliasing, macros, comportamiento indefinido, APIs del sistema operativo, concurrencia, manejo de errores, rendimiento, FFI, compatibilidad binaria y pruebas incompletas.

12. Qué significa para empresas con código legado en C

Para empresas que mantienen software crítico en C, la señal es clara: no hay que esperar una herramienta mágica, pero sí conviene preparar una hoja de ruta. Inventariar componentes, identificar módulos con mayor exposición, crear pruebas diferenciales, aislar APIs peligrosas, reducir superficie unsafe y evaluar Rust para nuevos desarrollos puede generar beneficios incluso antes de una migración completa.

13. La tendencia va más allá de Canonical

La migración automática hacia Rust forma parte de una tendencia mayor. DARPA lanzó TRACTOR con el objetivo de crear tecnología capaz de convertir C a Rust de calidad similar a la de un desarrollador experto, usando combinaciones de análisis de software y modelos de lenguaje. La existencia de programas como ese muestra que la seguridad de memoria dejó de ser una preocupación académica y se convirtió en prioridad estratégica.

Canonical, al financiar investigación universitaria con casos reales de Ubuntu, aporta algo importante a esa tendencia: repositorios maduros, problemas de producción y restricciones que no aparecen en benchmarks pequeños.

14. Preguntas clave

Recomendamos

En resumen

Canonical está apostando por una vía seria para llevar más Rust al corazón de Ubuntu: IA, sí, pero con validación, análisis formal, fuzzing y reparación automática. El proyecto no promete una sustitución inmediata de millones de líneas de C, sino una investigación de tres años para saber si grandes repositorios pueden migrarse de forma segura, correcta y mantenible.

La diferencia frente a otros anuncios de IA es el rigor. Canonical parte de una premisa prudente: el código generado no se debe confiar hasta demostrar que preserva el comportamiento del original. Esa visión puede marcar una ruta para empresas que quieren modernizar software crítico sin caer en la ilusión de que compilar equivale a estar seguro.