5 comments

  • kayo_2021103029 minutes ago
    I have no particular religious preference for a language. One uses what one feels is appropriate.<p>But, let&#x27;s say this effort is a complete success. What&#x27;s next?<p>Can all the maintainers of the c codebase move over to maintaining (forward) the Rust codebase. Surely there&#x27;ll be some friction, and losses to friction.<p>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 &quot;a player to be named later&quot;.
    • Insanity12 minutes ago
      I agree there&#x27;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 &quot;capable engineers can pick up any language&quot;. Sure, it&#x27;ll take time to learn these things, but it should not be a blocker.
      • modularitynew2 minutes ago
        Your argument about stagnation is good, but &quot;capable engineers can pick up any language&quot; 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 <a href="https:&#x2F;&#x2F;fasterthanli.me&#x2F;articles&#x2F;a-rust-match-made-in-hell" rel="nofollow">https:&#x2F;&#x2F;fasterthanli.me&#x2F;articles&#x2F;a-rust-match-made-in-hell</a> ), APIs, libraries, ecosystem, build systems, etc.<p>They would also have to figure out how to approach distribution, organization, linking, etc.
      • akazantsev8 minutes ago
        &gt; capable engineers can pick up any language<p>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?
  • djoldman20 minutes ago
    Not the same as:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;uutils&#x2F;coreutils" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;uutils&#x2F;coreutils</a><p>Although I could see them benefitting.
  • black_1344 minutes ago
    [dead]
  • jedisct157 minutes ago
    Have you heard about fil-c?
    • nu11ptr8 minutes ago
      It is a massive accomplishment and neat tool for sure but:<p>1) Induces a large performance penalty<p>2) Introduces a GC into C code bases (higher memory requirements, performance profile changes)<p>3) Is x86-64 only atm I believe<p>An idiomatic Rust port would have none of these issues, so it would be more a stop gap measure than a long term strategy.
    • Tuna-Fish41 minutes ago
      It&#x27;s an interesting option for infrastructure that&#x27;s not performance critical.<p>I agree with Domen Kožar that I want an extern &quot;fil-c&quot; in Rust. <a href="https:&#x2F;&#x2F;domenkozar.com&#x2F;2026&#x2F;08&#x2F;13&#x2F;i-want-extern-fil-c&#x2F;" rel="nofollow">https:&#x2F;&#x2F;domenkozar.com&#x2F;2026&#x2F;08&#x2F;13&#x2F;i-want-extern-fil-c&#x2F;</a>
      • actionfromafar7 minutes ago
        That would be amazing. A C to Rust port could start out with Rust with only a <i>fn main()</i> at first, then progressively moving more and more stuff &quot;up&quot; from the C program into Rust, making it faster and faster.
    • Almondsetat49 minutes ago
      What about it?
  • 189237930 minutes ago
    Why would Canonical even be an expert in this? They mostly have sysadmin types of employees.<p>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&#x27;s interest in Debian resolutions and control the Debian derivative market.
    • modularitynew9 minutes 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.<p>From the article:<p>&gt; 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.<p>uutils is licensed under MIT, instead of GPL like the original coreutils, and thus it would be easier to grab.<p>The article&#x27;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.<p>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 <a href="https:&#x2F;&#x2F;fasterthanli.me&#x2F;articles&#x2F;a-rust-match-made-in-hell" rel="nofollow">https:&#x2F;&#x2F;fasterthanli.me&#x2F;articles&#x2F;a-rust-match-made-in-hell</a> , some of Rust&#x27;s other features, like tagged unions and pattern matching, are by themselves attractive to many developers.
    • Insanity14 minutes ago
      I don&#x27;t see a reason to believe they&#x27;re not capable of doing this. Plus, it&#x27;s not only Canonical working on this, they are _funding_ the development in partnership with University of Bristol. They&#x27;ll obviously leverage AI to do part of this migration (as explained in TFA).<p>It&#x27;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&#x2F;OSS based projects so they&#x27;re not unique in this regard.
    • aw162110712 minutes ago
      &gt; Why would Canonical even be an expert in this?<p>Does it matter? The announcement is that they&#x27;re funding a PhD project. I don&#x27;t think it&#x27;s <i>that</i> unusual to fund a project whose outcome you are interested in even if you don&#x27;t have the expertise needed to carry it out yourself.