4 ms·

Canonical backs new project to translate large C codebases into safe Rust

40 points by datakan 1mo ago

jedisct1 1mo ago
Have you heard about fil-c?
- Almondsetat 1mo ago
  What about it?
- Tuna-Fish 1mo ago
  It's an interesting option for infrastructure that's not performance critical. I 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/ https://domenkozar.com/2026/08/13/i-want-extern-fil-c/
  - actionfromafar 1mo ago
    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.
- nu11ptr 1mo ago
  It is a massive accomplishment and neat tool for sure but: 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.
black_13 1mo ago
[dead]
1892379 1mo ago
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.
- Insanity 1mo ago
  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.
- aw1621107 1mo ago
  > Why would Canonical even be an expert in this? 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.
- modularitynew 1mo ago
  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 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.
kayo_20211030 1mo ago
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".
- Insanity 1mo ago
  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.
  - akazantsev 1mo ago
    > capable engineers can pick up any language Sure, given that they are getting paid for it. How many people will be interested in learning a programming language with insignificant job availability, in addition to contributing for free?
    - Insanity 1mo ago
      I find that many people contributing to OSS projects tend to be the ones passionate about programming and also pick up new languages "for fun". That could be my bubble though.
      - akazantsev 1mo ago
        Demanding others to pick up Rust "for fun" is not fun at all.
djoldman 1mo ago
Not the same as: https://github.com/uutils/coreutils https://github.com/uutils/coreutils Although I could see them benefitting.
dgan 1mo ago
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
- dmix 1mo ago
  The article says that is the whole question they are exploring and have 3yr project to try
qew16t 1mo ago
Great stuff. Instead of asking and funding the C developers of the respective projects for a port, they go for license washing and stealing.
ChrisArchitect 1mo ago
Source: https://discourse.ubuntu.com/t/investing-in-automated-c-to-rust-translation/86369 https://discourse.ubuntu.com/t/investing-in-automated-c-to-r... (https://news.ycombinator.com/item?id=49361334 https://news.ycombinator.com/item?id=49361334)
childintime 1mo ago
The Darpa Tractor project looks to achieve the same: https://news.ycombinator.com/item?id=41110269 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.
golbez9 1mo ago
Be serious about change, re-write it in Zig
learningstud 1mo ago
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.

40 points by datakan 1mo ago

jedisct1 1mo ago

Have you heard about fil-c?

Almondsetat 1mo ago
What about it?
Tuna-Fish 1mo ago
It's an interesting option for infrastructure that's not performance critical. I 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/ https://domenkozar.com/2026/08/13/i-want-extern-fil-c/
- actionfromafar 1mo ago
  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.
nu11ptr 1mo ago
It is a massive accomplishment and neat tool for sure but: 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.

black_13 1mo ago

[dead]

1892379 1mo ago

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.

Insanity 1mo ago
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.
aw1621107 1mo ago
> Why would Canonical even be an expert in this? 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.
modularitynew 1mo ago
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 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.

kayo_20211030 1mo ago

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".

Insanity 1mo ago
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.
- akazantsev 1mo ago
  > capable engineers can pick up any language Sure, given that they are getting paid for it. How many people will be interested in learning a programming language with insignificant job availability, in addition to contributing for free?
  - Insanity 1mo ago
    I find that many people contributing to OSS projects tend to be the ones passionate about programming and also pick up new languages "for fun". That could be my bubble though.
    - akazantsev 1mo ago
      Demanding others to pick up Rust "for fun" is not fun at all.

djoldman 1mo ago

Not the same as: https://github.com/uutils/coreutils https://github.com/uutils/coreutils Although I could see them benefitting.

dgan 1mo ago

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

dmix 1mo ago
The article says that is the whole question they are exploring and have 3yr project to try

qew16t 1mo ago

Great stuff. Instead of asking and funding the C developers of the respective projects for a port, they go for license washing and stealing.

ChrisArchitect 1mo ago

Source: https://discourse.ubuntu.com/t/investing-in-automated-c-to-rust-translation/86369 https://discourse.ubuntu.com/t/investing-in-automated-c-to-r... (https://news.ycombinator.com/item?id=49361334 https://news.ycombinator.com/item?id=49361334)

childintime 1mo ago

The Darpa Tractor project looks to achieve the same: https://news.ycombinator.com/item?id=41110269 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.

golbez9 1mo ago

Be serious about change, re-write it in Zig

learningstud 1mo ago

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.