Canonical's fondness for AI and Rust is no secret. Now it is co-funding a three-year PhD project investigating whether the former can translate large C codebases into the latter.
Engineering veep Jon Seager announced the investment on Ubuntu's Discourse forum. The PhD project will be conducted at the University of Bristol's Programming Languages Research Group.
So don't panic. This is not an announcement that Canonical will turn the bots loose to rewrite all of Ubuntu as Rusty slop. (For a start, nobody can afford that many tokens.) Instead of burning dosh on bots, Canonical will pay a proto-boffin to spend several years investigating whether the idea can be made to work. That is welcome. In an industry overflowing with hype, the project should produce evidence about whether this approach can be useful.
The Reg FOSS desk interviewed Seager last year, and he struck us as sensible and pragmatic, but not lacking in boldness. Under his guidance, Ubuntu 25.10 adopted a Rust implementation of sudo as well as the entirely separate Rust-based uutils coreutils. The sudo command did hit some problems but they were quickly fixed.
Both uutils and sudo-rs were pre-existing independent projects, however. They are human-written replacements designed to reproduce the functionality of existing tools using entirely new codebases. Certainly, those human developers may have studied the original source code – that's one of the good things about FOSS, after all – but these are new implementations.
The new project will investigate whether an LLM can take programs "comprising hundreds of thousands of lines of C" and decompose them into smaller components before using an LLM to rewrite those components in "safe, behaviourally correct and maintainable Rust."
Seager's post runs to just over 1,000 words and addresses several objections that sprang to mind. For instance, existing tools attempt something similar, but their results leave much to be desired.
As Seager puts it: "Traditional source-to-source translators can process substantial amounts of code, but often preserve the structure of the C too literally. The result may compile as Rust, but still rely heavily on unsafe operations, retain awkward C idioms and require significant manual work before it resembles code a Rust maintainer would choose to own."
MORE CONTEXT
We suggest reading the post before attacking the idea. It sets out a relatively detailed and measured plan. One admirable aspect is its acknowledgment that mature codebases contain knowledge their programmers never consciously documented. Years of fixes and patches encode responses to real-world corner cases that nobody anticipated at the outset. This is the key argument of Joel Spolsky's 2000 essay: Things You Should Never Do, Part I. Such knowledge is rarely documented outside the code itself or, if you're lucky, a few comments. A machine translation might preserve some of that behavior, while a clean human rewrite based on the original design could miss it.
The proposal names two specific tools that the effort intends to examine: snap-confine and AppArmor We may be excessively cynical, but openSUSE 16 replaced AppArmor with SELinux last year. Outside the Ubuntu family, enterprise Linux has largely consolidated around the more complex SELinux, although Debian and several smaller distributions continue to support AppArmor. A hardened Rust implementation could therefore benefit AppArmor's remaining users. Snap, of course, has a narrower constituency still.
This is not a solo Canonical project. The company is co-sponsoring it with UK Research and Innovation, a public body sponsored by the UK's Department for Business, Innovation, Science and Trade. Seager will oversee the project alongside the University of Bristol's Professor Meng Wang and Dr Cristina David.
Three years is a conventional duration for a UK PhD – provided it does not overrun, of course. It's not as if someone could go into a PhD program in 1998 and then get two decades' worth of comic strips out of it or something.
The Reg FOSS desk remains staunchly skeptical of generative AI outside the narrow domain of translation between human languages. As such, we have grave doubts that this will prove viable. We suspect the difficult part will not be translating the code, but decomposing a large codebase into smaller components that bots can digest. The challenge recalls the long-running effort to divide arbitrary algorithms automatically into tasks that can be farmed out to parallel processes. Decades of research have produced useful techniques for particular cases, but no general solution. It may yet prove to be an incomputable problem, like the Halting Problem – and as that article says, if it could be solved, it would lead to solutions to the Busy Beaver function or even Goldbach's conjecture.
As with much of generative AI, more evidence is needed, and producing it is exactly what a PhD research project should do. We salute Canonical for putting real money behind the question and would be delighted to have our skepticism proved wrong. As we speculated in 2024, automatic translation between programming languages could become immensely valuable for improving software reliability – not by fixing problems automatically, but by exposing previously unknown errors. ®
