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