Canonical Joins Rust Foundation (nerds.xyz) 31
BrianFagioli writes: Canonical has joined the Rust Foundation as a Gold Member, signaling a deeper investment in the Rust programming language and its role in modern infrastructure. The company already maintains an up-to-date Rust toolchain for Ubuntu and has begun integrating Rust into parts of its stack, citing memory safety and reliability as key drivers. By joining at a higher tier, Canonical is not just adopting Rust but also stepping closer to its governance and long-term direction.
The move also highlights ongoing tensions in Rust's ecosystem. While Rust can reduce entire classes of bugs, it often depends heavily on external crates, which can introduce complexity and auditing challenges, especially in enterprise environments. Canonical appears aware of that tradeoff and is positioning itself to influence how the ecosystem evolves, as Rust continues to gain traction across Linux and beyond. "As the publisher of Ubuntu, we understand the critical role systems software plays in modern infrastructure, and we see Rust as one of the most important tools for building it securely and reliably. Joining the Rust Foundation at the Gold level allows us to engage more directly in language and ecosystem governance, while continuing to improve the developer experience for Rust on Ubuntu," said Jon Seager, VP Engineering at Canonical. "Of particular interest to Canonical is the security story behind the Rust package registry, crates.io, and minimizing the number of potentially unknown dependencies required to implement core concerns such as async support, HTTP handling, and cryptography -- especially in regulated environments."
The move also highlights ongoing tensions in Rust's ecosystem. While Rust can reduce entire classes of bugs, it often depends heavily on external crates, which can introduce complexity and auditing challenges, especially in enterprise environments. Canonical appears aware of that tradeoff and is positioning itself to influence how the ecosystem evolves, as Rust continues to gain traction across Linux and beyond. "As the publisher of Ubuntu, we understand the critical role systems software plays in modern infrastructure, and we see Rust as one of the most important tools for building it securely and reliably. Joining the Rust Foundation at the Gold level allows us to engage more directly in language and ecosystem governance, while continuing to improve the developer experience for Rust on Ubuntu," said Jon Seager, VP Engineering at Canonical. "Of particular interest to Canonical is the security story behind the Rust package registry, crates.io, and minimizing the number of potentially unknown dependencies required to implement core concerns such as async support, HTTP handling, and cryptography -- especially in regulated environments."
a corporation gave some money... (Score:4, Insightful)
In other words, some corporation donated some money, perhaps to buy some influence.
"... it often depends heavily on external crates, which can introduce complexity and auditing challenges, especially in enterprise environments."
Give something a new name then pretend it's a new solution. If only anyone had thought of any of this before!
"Canonical appears aware of that tradeoff and is positioning itself to influence how the ecosystem evolves, as Rust continues to gain traction across Linux and beyond."
So absolutely nothing.
Re: (Score:2)
In other words, some corporation donated some money, perhaps to buy some influence.
Exactly. If you want a seat at the table to be part of the conversation you need to be a part of the foundation.
Re: a corporation gave some money... (Score:2)
Let me translate:
"... it often depends heavily on external crates, which can introduce complexity and auditing challenges, especially in enterprise environments."
"If you write code in rust, you may link to a library in your code. I think this is somehow unique to rust, but I have no experience in software development. That makes rust more challenging in Enterprise environments."
Re: (Score:2)
That other things are also bad is no reason to not try to look at and change your own situation.
Re: (Score:2)
You''ve added the word 'more' here and that wasn't in the original statement.
Rust depends on external libraries more than other languages do, because the Rust standard library does not include "core concerns such as async support, HTTP handling, and cryptography", as per the article. Languages like Java, and Go have large standard libraries that do all these things. Rust does not. I believe Rust has a philosophy of not wanting to commit to specific libraries, but instead let programmers pick the best libraries.
Re: a corporation gave some money... (Score:1)
This is a long-solved problem in every language. See for example artifactory, which is very common in enterprise settings. If you're not already using software supply chain tooling to manage exactly this, even if you're not doing software development at all, then you've got much bigger problems. So if it's not "more", then it's literally nothing at all.
Re: a corporation gave some money... (Score:4, Insightful)
The difference is that everything is statically linked in Rust. This isn't a problem if you rebuild the universe and release every day anyway, fix the library and everything will pick it up.
But it's an issue for Canonical (and Debian) because they don't rebuild every one of the tens if not hundreds of thousands of packages for each update of the Release file. And this would have to include older releases too that are still supported.
With many languages, if you rebuild the .so then that's all that is needed. Sure end users need to restart processes to be sure of picking up the fix but that's all. Debian tries quite hard to avoid library bundling where possible but rust sort of makes it implicit anyway.
The downside of the shared library model is that any and every incompatible library change requires a soname bump. ABI stability is critical to the .so model.
Re: (Score:2)
I prefer the statically linked model, just because it means less stuff that can go wrong. A binary that runs on Debian will run on RedHat. Yes, some stuff like libc may be an issue, but with static linking, anything above that should be there in some capacity.
It also allows easier use of backported libraries. For example, if a library is tested, audited and certified, it can be critical that it, at that specific version, be included, and not a newer one, as a newer one may introduce bugs that were not pr
Re: (Score:3)
The difference is that everything is statically linked in Rust.
That's not correct: Rust fully supports [medium.com] dynamic linking. Just add a --crate-type option to tell it whether to use static or dynamic.
This is similar to C, C++, Java, and most other compiled libraries.
Ada Redux (Score:1)
Re: (Score:2)
The only reason rust works for graphic drivers is because in the end a well defined C API is exposed (Vulkan/OpenGL/OpenCL).
It works in the kernel because that gets completely rebuilt every time. I'm curious what will happen once there will be a lot of rust code and they will want to bump the rust version, will it be automatable?
This pretty much sums up the use of rust: a monolith that maybe in the end exposes an Inter-Binary-Communication interface. One rustacean recommended I do my library as a microservi
Re: (Score:3)
"If you write code in rust, you may link to a library in your code. I think this is somehow unique to rust, but I have no experience in software development. That makes rust more challenging in Enterprise environments."
The standard Rust competitor is C++. That has a very different design choice - the standard library is huge, ancient and ever expanding and basically requires backwards compatibility. However, that also means that you know that your compiler vendor or specific standard library vendor has to provide those functions for certification and that there's some basic level of support and responsibility for the contents. Likely similar to or related to the level you get for the compiler.
With Rust's choice you get a
Re: (Score:2)
The Rust crates.io (which is what we're talking about) situation is bad. It's in some ways worse than NPM or Composer because in both of the latter cases you can see that the project uses NPM or Composer when you set it up, while Rust's crates.io thing is built-in functionality, and it's not really possible to find out what the dependencies are without grepping the source code.
Java, likewise, has no dependency resolver built into it, and in general the approach is better:
- Java programs are memory safe by d
Has there been... (Score:2)
Rust could be awesome. (Score:3, Insightful)
The religious zeal and the push to Rustify things that are harmed by premature Rustification makes Rust and the Rust community look really bad.
Re: (Score:1)
Maybe when it slows down it will be better, then you can count on things working from version to version.
Oh wait, I forgot the Python example.
Nahhhhh
Re: (Score:3)
Yeah, not sure if you remember the Vegan Crossfit Pythonistas.
Instead of saying, "we could write a program to..." they would dogmatically intone, "we could write a Python script to..." in almost every situation.
Not sure who taught them the NLP but their dedication was a fervor.
A whole lot of rewriting of fast, debugged, working code got rewritten by them just because Perl, Ruby, and Bash felt like heresy.. For a while python stacktraces were the error message of common use on Fedora.
Re: (Score:2, Interesting)
P.S. "Rewrite it in X" is as old as the programming itself, but there wasn't yet such a major step forward in the whole industry in the short term. Also Rust is a pleasant language to use, regardless of it's safety guarantees,
Re: (Score:2)
Re: (Score:1)
That said, if you replace parts of the system with incomplete parts because the Rust tool chain is incomplete, you get angry people yelling about how the new Rust replacement can not do the things that they counted on that system to do. Then the Rust zealots tell us why we don't need to do that and that we should completely recode everything we have to work with the new hotness.
"We do not break user-space"
Unless it is done to Rustify something. Then, fuck user-s
Re: (Score:2)
Re: (Score:1)
Ubuntu 25.10.
What is a foundational tenet of Linux? "We do not break user-space."
But, we do for Rust. Why? Because Rust MUST move forward at speed. Can't pass tests? Fuck it. Works good enough.
Breaks user-space? Yes, but not all the time and not for most people. We are accepting Rust CoreUtils for no other reason that it must be.
It has been decreed. Ubuntu about CoreUtils is Bill, "Fuck it, we'll do LIVE!".
Large performance hiccups, f
Re: (Score:2)
Re: (Score:3)
Having been using Rust for six years and interacting with Rust devs and other users I see no evidence of that "religion" of which you speak. Pretty much all of them advise against rewriting old code bases just because Rust. They know the effort, time and expense that can take and the problems it can cause. Rather they emphasis symbiosis with other languages.
In short, what are you talking about?
Re: (Score:1)
Having been using Rust for six years and interacting with Rust devs and other users I see no evidence of that "religion" of which you speak. Pretty much all of them advise against rewriting old code bases just because Rust. They know the effort, time and expense that can take and the problems it can cause. Rather they emphasis symbiosis with other languages.
In short, what are you talking about?
I always found the dubious moniker of "system language" pretty faddish. Even before there were any working examples. That along with how people repeated that claim also without examples. Then the quiet retreat from that claim after the fact?
Re: (Score:2)
I see no evidence of that "religion" of which you speak.
Ubuntu 25.10
Is that evidence enough? "We do not break user-space."
Unless it is to implement Rust based tools in spite of knowing that they fail tests and break user-space. KNOWINGLY
There is definitely a problem. Not with creating Rust. Not with replacing things that can be replaced.
When thought, they knowingly break a foundational rule to implement their religion, it makes the point.
Re: (Score:2)
Rust could be awesome, if it developed like a normal language instead of a religion. The religious zeal and the push to Rustify things that are harmed by premature Rustification makes Rust and the Rust community look really bad.
Swift was introduced and phased in the right way. If we are talking programing for (aside from macOS) Windows or FreeBSD, then it would seem like Swift is already there. In fact, it even seems to be there on Linux
Why not pick that instead of Rust?
Re: (Score:1)
Why not pick that instead of Rust?
Because then it would not be religious zealotry? :)
Re: (Score:2)
Exactly.
I might agree with or not agree with the politics of people building Rust things, or even the language, but that’s fine and shouldn’t really matter, unless they bring their politics into the language itself, OR do completely idiotic things like try to rewrite core utilities in Rust (not the issue) and then *ship them before they’re fucking perfect* (the really big issue).
Emphasis on the end.
We’ll never agree with everyone else in OSS on philosophy, but we should agree on meri
Rust and AI are trying to solve the wrong problem (Score:2)
Rust is a cult. (Score:2)
https://www.phoronix.com/news/... [phoronix.com]