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.
Your argument about stagnation is good, but "capable engineers can pick up any language" is not without costs for the involved developers in terms of time spent learning paradigms, features, bugs, gotchas (like temporary lifetime gotchas in Rust encouraged by the constraints of the borrow checker, still a widespread issue in 2026 https://fasterthanli.me/articles/a-rust-match-made-in-hell ), APIs, libraries, ecosystem, build systems, etc.
They would also have to figure out how to approach distribution, organization, linking, etc.
Yup it's not without cost. But paying the cost short-term can yield benefits for the long-term.
I'm not defending Rust as the specific here though, I'm discussing it a bit more abstractly in regards to "moving from tech A to tech B". I've only dabbled with Rust, but from what I can tell it _should_ improve overall quality of codebases over time by reducing some of the more painful footguns of C.
> Yup it's not without cost. But paying the cost short-term can yield benefits for the long-term.
That was not really the vibe I got from your (Insanity) other comment regarding your mental model that you mentioned. "Not a blocker" is somewhat dismissive of costs, since there are cases where the costs can be so high that they are a blocker.
It is also worsened by the risk that it might cost more long-term than it yields, given the issues of Rust, both generally, and specifically to Canonical's needs. Though, C is indeed an ancient and minimalistic language that also has issues.
And then there is the whole aspect of license changes from GPL to MIT through rewriting to Rust.
For the Linux kernel, arguably a somewhat different domain, there are still a lot of features for Rust on the official wishlist that seem far away. Like the minor feature of bitfields, where it is not a core part of the Rust language. And there is the lack of an international standard, or even a regular standard, the document derived from Ferrocene had severe shortcomings and holes last I checked. And then there is the hostility among some in the Rust community towards gccrs, despite gcc possibly being more popular than LLVM in the software projects that Canonical uses or handles.
Definitely case-by-case basis. I'm really not trying to defend Rust or the specifics of this project. But generally learning a new language being a blocker for capable engineering teams is a questionable statement. It definitely can be in practice, because maybe your company has 0 tolerance / budget for learning something new.
But without getting bogged down in specifics, I do stand by the fact that I don't think learning a new language should be a blocker for many in practice.
Is it "widespread"? The article you link is from 2022 and none of the discussion I saw on said article gave me the impression that it was particularly common issue back then, let alone now.
It is a mess, temporary lifetime extension is a mess in both Rust, C++ and Zig (despite Zig not having RAII unlike Rust and C++). Interestingly, Mojo might avoid some or all of that, by having some destructors be implicit, and some destructors be explicit, https://mojolang.org/docs/manual/lifecycle/death/ , requiring users to write the destructors manually. Thus, a lock in Mojo can be forced by the compiler to be explicit, and that prevents the Rust problem of https://fasterthanli.me/articles/a-rust-match-made-in-hell , since developers will have to explicitly destroy the lock in Mojo. C also does not have that temporary lifetime extension issue, since there is barely any temporary lifetime extension in C, apart possibly from compound literals, but compound literals might also have some issues and involved rules.
The edition system in Rust tripping LLMs up is not great either. That can happen because the same code in one edition of Rust can have very different behavior in another edition of Rust, like the same piece of Rust code having a deadlock in one edition and not in another.
Interesting, thanks for the links! I'm curious as to how many of the apparent issues are attributable to lifetime extension specifically as opposed to something else like async-related deadlocks as mentioned in the parent to the first linked comment (which I feel I've heard much more about), especially after the Rust 2024 changes.
That being said, after a bit more searching I found this 2023 blog from one of the Rust devs [0] which supports the "widespread" description at the time:
> One very common problem is deadlocks (or panics, for ref-cell) when mutex locks occur in a match scrutinee
so I think we can chalk this up to me being insufficiently well-read. I think it would be interesting to see to what extent the Rust 2024 changes alleviated the problem since it only changed if let, but I haven't found that information (yet).
There's also this related work [1], but I think the scope of that is rather larger.
> Interestingly, Mojo might avoid some or all of that, by having some destructors be implicit, and some destructors be explicit, [] , requiring users to write the destructors manually.
There's some relevant exploration being done in Rust that in principle could enable linear types [2], though obviously it remains to be seen to what extent this work will pan out.
> I think it would be interesting to see to what extent the Rust 2024 changes alleviated the problem since it only changed if let, but I haven't found that information (yet).
Regarding "super let", it looks interesting, but I am not sure about the details of it. This is the tracking GitHub issue https://github.com/rust-lang/rust/issues/139076 . There is also the challenge of backwards compatibility, which makes the feature harder to make good, I suspect.
Aside that, I did not make any arguments either way regarding your question. But, I am not sure that your question makes sense in this context, for the developers that are available to a given project are generally part of the considerations for that project. For instance, if a company has a number of existing employees and are not in a position to attract new ones, the existing employees absolutely have to be considered, even ignoring any negotiation kind of stuff. Conversely, if a company has no current employees (like a newly minted startup) or is in a great position to attract lots of new employees, then the company at least has the option of selecting new employees to fit the rest of their goals and constraints. Though even in the latter case, considering existing employees can often make a lot of sense or be necessary.
For Canonical as well as the Linux kernel, I think I have heard arguments about attracting new developers by switching to Rust, and there has on the other hand been concerns regarding existing developers, not all of whom might be interested or experienced in Rust, some existing developers have complained in public. But there is a lot of know-how, expertise and domain knowledge independent of the language in both the Linux kernel and the software that Canonical handles or uses, and that knowledge and expertise are not necessarily easy to acquire quickly. And then there are all the borrow checker problems and other kinds of problems with Rust, making Rust, even for greenfield projects, less attractive. Rust does have nice pattern matching, though.
I believe that one should optimize for the needs of the business that uses the project/software. SaaS, Open Source and internally used proprietary software have different optimization parameters.
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?
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.
It's the beauty of the OSS community. Someone will think Rust is fun, pick it up, and contribute. No one is _demanding_ it per se. If you don't like it, you just don't contribute anymore.
I'm brushing over it lightly, I do understand this will impact people who were passionate about the project and now feel like they can't contribute anymore. Definitely an impact on an individual level. But that is, for better or worse, part of open source.
> 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
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.
As a former Canonical 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.
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.
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.
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.
Your argument about stagnation is good, but "capable engineers can pick up any language" is not without costs for the involved developers in terms of time spent learning paradigms, features, bugs, gotchas (like temporary lifetime gotchas in Rust encouraged by the constraints of the borrow checker, still a widespread issue in 2026 https://fasterthanli.me/articles/a-rust-match-made-in-hell ), APIs, libraries, ecosystem, build systems, etc.
They would also have to figure out how to approach distribution, organization, linking, etc.
Yup it's not without cost. But paying the cost short-term can yield benefits for the long-term.
I'm not defending Rust as the specific here though, I'm discussing it a bit more abstractly in regards to "moving from tech A to tech B". I've only dabbled with Rust, but from what I can tell it _should_ improve overall quality of codebases over time by reducing some of the more painful footguns of C.
> Yup it's not without cost. But paying the cost short-term can yield benefits for the long-term.
That was not really the vibe I got from your (Insanity) other comment regarding your mental model that you mentioned. "Not a blocker" is somewhat dismissive of costs, since there are cases where the costs can be so high that they are a blocker.
It is also worsened by the risk that it might cost more long-term than it yields, given the issues of Rust, both generally, and specifically to Canonical's needs. Though, C is indeed an ancient and minimalistic language that also has issues.
And then there is the whole aspect of license changes from GPL to MIT through rewriting to Rust.
For the Linux kernel, arguably a somewhat different domain, there are still a lot of features for Rust on the official wishlist that seem far away. Like the minor feature of bitfields, where it is not a core part of the Rust language. And there is the lack of an international standard, or even a regular standard, the document derived from Ferrocene had severe shortcomings and holes last I checked. And then there is the hostility among some in the Rust community towards gccrs, despite gcc possibly being more popular than LLVM in the software projects that Canonical uses or handles.
Definitely case-by-case basis. I'm really not trying to defend Rust or the specifics of this project. But generally learning a new language being a blocker for capable engineering teams is a questionable statement. It definitely can be in practice, because maybe your company has 0 tolerance / budget for learning something new.
But without getting bogged down in specifics, I do stand by the fact that I don't think learning a new language should be a blocker for many in practice.
> still a widespread issue in 2026
Is it "widespread"? The article you link is from 2022 and none of the discussion I saw on said article gave me the impression that it was particularly common issue back then, let alone now.
Indeed it is, read this:
https://old.reddit.com/r/rust/comments/1v54et2/what_are_the_...
https://old.reddit.com/r/rust/comments/1v54et2/what_are_the_...
Links for anyone without a Reddit account:
https://redlib.catsarch.com/r/rust/comments/1v54et2/what_are...
https://redlib.catsarch.com/r/rust/comments/1v54et2/what_are...
It is a mess, temporary lifetime extension is a mess in both Rust, C++ and Zig (despite Zig not having RAII unlike Rust and C++). Interestingly, Mojo might avoid some or all of that, by having some destructors be implicit, and some destructors be explicit, https://mojolang.org/docs/manual/lifecycle/death/ , requiring users to write the destructors manually. Thus, a lock in Mojo can be forced by the compiler to be explicit, and that prevents the Rust problem of https://fasterthanli.me/articles/a-rust-match-made-in-hell , since developers will have to explicitly destroy the lock in Mojo. C also does not have that temporary lifetime extension issue, since there is barely any temporary lifetime extension in C, apart possibly from compound literals, but compound literals might also have some issues and involved rules.
The edition system in Rust tripping LLMs up is not great either. That can happen because the same code in one edition of Rust can have very different behavior in another edition of Rust, like the same piece of Rust code having a deadlock in one edition and not in another.
Interesting, thanks for the links! I'm curious as to how many of the apparent issues are attributable to lifetime extension specifically as opposed to something else like async-related deadlocks as mentioned in the parent to the first linked comment (which I feel I've heard much more about), especially after the Rust 2024 changes.
That being said, after a bit more searching I found this 2023 blog from one of the Rust devs [0] which supports the "widespread" description at the time:
> One very common problem is deadlocks (or panics, for ref-cell) when mutex locks occur in a match scrutinee
so I think we can chalk this up to me being insufficiently well-read. I think it would be interesting to see to what extent the Rust 2024 changes alleviated the problem since it only changed if let, but I haven't found that information (yet).
There's also this related work [1], but I think the scope of that is rather larger.
> Interestingly, Mojo might avoid some or all of that, by having some destructors be implicit, and some destructors be explicit, [] , requiring users to write the destructors manually.
There's some relevant exploration being done in Rust that in principle could enable linear types [2], though obviously it remains to be seen to what extent this work will pan out.
[0]: https://smallcultfollowing.com/babysteps/blog/2023/03/15/tem...
[1]: https://blog.m-ou.se/super-let/
[2]: https://github.com/rust-lang/goals/blob/main/src/2026/move-t...
> I think it would be interesting to see to what extent the Rust 2024 changes alleviated the problem since it only changed if let, but I haven't found that information (yet).
The second link from Reddit, https://redlib.catsarch.com/r/rust/comments/1v54et2/what_are... , claims that some issues were made worse in practice in his experience by Rust edition 2024.
Regarding "super let", it looks interesting, but I am not sure about the details of it. This is the tracking GitHub issue https://github.com/rust-lang/rust/issues/139076 . There is also the challenge of backwards compatibility, which makes the feature harder to make good, I suspect.
Would you agree that one should optimize for the project / software, rather that optimize for any individual programmer on it?
> that
should be
> than
in your comment.
Aside that, I did not make any arguments either way regarding your question. But, I am not sure that your question makes sense in this context, for the developers that are available to a given project are generally part of the considerations for that project. For instance, if a company has a number of existing employees and are not in a position to attract new ones, the existing employees absolutely have to be considered, even ignoring any negotiation kind of stuff. Conversely, if a company has no current employees (like a newly minted startup) or is in a great position to attract lots of new employees, then the company at least has the option of selecting new employees to fit the rest of their goals and constraints. Though even in the latter case, considering existing employees can often make a lot of sense or be necessary.
For Canonical as well as the Linux kernel, I think I have heard arguments about attracting new developers by switching to Rust, and there has on the other hand been concerns regarding existing developers, not all of whom might be interested or experienced in Rust, some existing developers have complained in public. But there is a lot of know-how, expertise and domain knowledge independent of the language in both the Linux kernel and the software that Canonical handles or uses, and that knowledge and expertise are not necessarily easy to acquire quickly. And then there are all the borrow checker problems and other kinds of problems with Rust, making Rust, even for greenfield projects, less attractive. Rust does have nice pattern matching, though.
I believe that one should optimize for the needs of the business that uses the project/software. SaaS, Open Source and internally used proprietary software have different optimization parameters.
> 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?
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.
Demanding others to pick up Rust "for fun" is not fun at all.
It's the beauty of the OSS community. Someone will think Rust is fun, pick it up, and contribute. No one is _demanding_ it per se. If you don't like it, you just don't contribute anymore.
I'm brushing over it lightly, I do understand this will impact people who were passionate about the project and now feel like they can't contribute anymore. Definitely an impact on an individual level. But that is, for better or worse, part of open source.
> 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.
The Darpa Tractor project looks to achieve the same:
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.
Great stuff. Instead of asking and funding the C developers of the respective projects for a port, they go for license washing and stealing.
Not the same as:
https://github.com/uutils/coreutils
Although I could see them benefitting.
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
Source: https://discourse.ubuntu.com/t/investing-in-automated-c-to-r... (https://news.ycombinator.com/item?id=49361334)
Have you heard about fil-c?
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/
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.
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.
What about it?
[dead]
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.
As a former Canonical 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.
None of them were "sysadmin" people.
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.
> 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.
> They mostly have sysadmin types of employees.
What on earth led you to that conclusion?
Maybe Canonical employees ruthlessly patching and breaking upstream at Debian?
Again, how is that an indication of "sysadmin" type employees rather than misaligned SWEs?