That would be amazing. A C to Rust port could start out with Rust with only a fn main() at first, then progressively moving more and more stuff "up" from the C program into Rust, making it faster and faster.
Why would Canonical even be an expert in this? They mostly have sysadmin types of employees.
The (elusive) end goal is of course to steal all C code bases, fully automate Debian with LLMs, fire all useful idiots who vote in Canonical's interest in Debian resolutions and control the Debian derivative market.
I don't see a reason to believe they're not capable of doing this. Plus, it's not only Canonical working on this, they are _funding_ the development in partnership with University of Bristol. They'll obviously leverage AI to do part of this migration (as explained in TFA).
It'll be interesting to see how successful this research project can be. Plus, moving to Rust is a long-term strategy adopted by various other Linux/OSS based projects so they're not unique in this regard.
Does it matter? The announcement is that they're funding a PhD project. I don't think it's that unusual to fund a project whose outcome you are interested in even if you don't have the expertise needed to carry it out yourself.
Even without any LLM usage after the rewrite, there might be a change in license as seen with similar projects, which supports your argument.
From the article:
> The company points to projects such as uutils coreutils and sudo-rs as examples of Rust implementations that have earned a place in the distribution.
uutils is licensed under MIT, instead of GPL like the original coreutils, and thus it would be easier to grab.
The article's claim that the Rust implementations earned their place in the distributions is also not true, it was more that they were forced into Ubuntu despite bugs and memory unsafety in the Rust implementations.
The general trend is interesting. C is an ancient language, and it is also minimalistic. And while Rust has lots of features with lots of problems, like its borrow checker that among other problems drives code towards deadlocks and TOCTOU bugs https://fasterthanli.me/articles/a-rust-match-made-in-hell , some of Rust's other features, like tagged unions and pattern matching, are by themselves attractive to many developers.
As a former employee, where I was the leader and engineering owner of Cloud and Server products, you are pretty off the mark here.
In my >25 year career, my team were the best engineers I have worked with and I'd work again with any of them in a heart-beat. Most of them have moved on to other impactful roles at other organisations and delivering amazing things.
I have no particular religious preference for a language. One uses what one feels is appropriate.
But, let's say this effort is a complete success. What's next?
Can all the maintainers of the c codebase move over to maintaining (forward) the Rust codebase. Surely there'll be some friction, and losses to friction.
What about deployments, monitoring, support and trouble-shooting? Are the teams that perform those functions now capable of performing those functions in the future? It seems to me that the here-to-there for functional, evolving and reliable systems in the real world has been elided and become simply "a player to be named later".
I agree there's some risk involved here, but the kind of thinking that you should stick to what you know can lead to stagnation. I much prefer the mental model of "capable engineers can pick up any language". Sure, it'll take time to learn these things, but it should not be a blocker.
> Can all the maintainers of the c codebase move over to maintaining (forward) the Rust codebase. Surely there'll be some friction, and losses to friction.
there are always losses. Anyone who can maintain a non-trival C code base can maintain Rust. It will take them some time to learn, but learning a new programming language is not hard for someone who wants to. In a couple years they will be just as productive.
The question is do they want to? I do not have much hope the existing maintainers will move. Some will, but I expect the majority will not.
If a business decides to migrate from X-lang to Y-lang (or X-system to Y-system) for some particular and sensible reason can the business afford to spend a couple of years to restore its productivity to what it was?
It might, but there'll be a significant cost, even outside of developer attrition. In a lot of operating businesses the opportunity cost is quite high given all the moving parts that sustain its current operations i.e. people, processes, etc.
It's a tough call; and a one-time automated code conversion may be the smallest part of it.
My company spent over a billion dollars just to rewrite a C++ project with a lot of technical debt in C++. We are finally making money after the rewrite, but that was a lot of cost and I honestly cannot recommend it to anyone.
I lean to what I'm trying to figure out how to do now: how do I rewrite the small parts that change the most into something else while keeping the whole working all along. Best part is other people are already at different points in the journey and we don't have to all move at once, nor pay the price all at once.
can it be done? C codebase are obviously missing the lifetime information, type-generic arguments are just void*, in/out arguments aren't explicit... or at least, the information is scattered across the codebase, and might be inconsistent. a "safe rust" might not be even possible
The real difficulty of systems programming in C is due to syscall/POSIX/libc semantics like the interplay between signal handling and async readv/writev resumption. These things are way beyond what the borrow checker and coverage-guided fuzzers can deal with and consist the bulk of vulnerabilities. Rust won't save you from CopyFail; you would need hardcore formal verification like TLA+ coupled with F* /Low* /Pulse to catch it before release. AI (or manual) Rust rewrites of well trodden C code is calling for trouble more than anything else.
26 comments
[ 0.21 ms ] story [ 27.8 ms ] threadI agree with Domen Kožar that I want an extern "fil-c" in Rust. https://domenkozar.com/2026/08/13/i-want-extern-fil-c/
1) Induces a large performance penalty
2) Introduces a GC into C code bases (higher memory requirements, performance profile changes)
3) Is x86-64 only atm I believe
An idiomatic Rust port would have none of these issues, so it would be more a stop gap measure than a long term strategy.
The (elusive) end goal is of course to steal all C code bases, fully automate Debian with LLMs, fire all useful idiots who vote in Canonical's interest in Debian resolutions and control the Debian derivative market.
It'll be interesting to see how successful this research project can be. Plus, moving to Rust is a long-term strategy adopted by various other Linux/OSS based projects so they're not unique in this regard.
Does it matter? The announcement is that they're funding a PhD project. I don't think it's that unusual to fund a project whose outcome you are interested in even if you don't have the expertise needed to carry it out yourself.
From the article:
> The company points to projects such as uutils coreutils and sudo-rs as examples of Rust implementations that have earned a place in the distribution.
uutils is licensed under MIT, instead of GPL like the original coreutils, and thus it would be easier to grab.
The article's claim that the Rust implementations earned their place in the distributions is also not true, it was more that they were forced into Ubuntu despite bugs and memory unsafety in the Rust implementations.
The general trend is interesting. C is an ancient language, and it is also minimalistic. And while Rust has lots of features with lots of problems, like its borrow checker that among other problems drives code towards deadlocks and TOCTOU bugs https://fasterthanli.me/articles/a-rust-match-made-in-hell , some of Rust's other features, like tagged unions and pattern matching, are by themselves attractive to many developers.
What on earth led you to that conclusion?
In my >25 year career, my team were the best engineers I have worked with and I'd work again with any of them in a heart-beat. Most of them have moved on to other impactful roles at other organisations and delivering amazing things.
None of them were "sysadmin" people.
But, let's say this effort is a complete success. What's next?
Can all the maintainers of the c codebase move over to maintaining (forward) the Rust codebase. Surely there'll be some friction, and losses to friction.
What about deployments, monitoring, support and trouble-shooting? Are the teams that perform those functions now capable of performing those functions in the future? It seems to me that the here-to-there for functional, evolving and reliable systems in the real world has been elided and become simply "a player to be named later".
there are always losses. Anyone who can maintain a non-trival C code base can maintain Rust. It will take them some time to learn, but learning a new programming language is not hard for someone who wants to. In a couple years they will be just as productive.
The question is do they want to? I do not have much hope the existing maintainers will move. Some will, but I expect the majority will not.
It might, but there'll be a significant cost, even outside of developer attrition. In a lot of operating businesses the opportunity cost is quite high given all the moving parts that sustain its current operations i.e. people, processes, etc.
It's a tough call; and a one-time automated code conversion may be the smallest part of it.
I lean to what I'm trying to figure out how to do now: how do I rewrite the small parts that change the most into something else while keeping the whole working all along. Best part is other people are already at different points in the journey and we don't have to all move at once, nor pay the price all at once.
https://github.com/uutils/coreutils
Although I could see them benefitting.
https://news.ycombinator.com/item?id=41110269
Just a few weeks back it was judged as unlikely to succeed. Now Canonical want to get in.