Canonical Joins Rust Foundation (nerds.xyz)
- Reference: 0181089490
- News link: https://news.slashdot.org/story/26/03/23/2340216/canonical-joins-rust-foundation
- Source link: https://nerds.xyz/2026/03/canonical-rust-foundation/
> Canonical has [2]joined the Rust Foundation as a [3]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 [4]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."
[1] https://slashdot.org/~BrianFagioli
[2] https://canonical.com/blog/canonical-joins-the-rust-foundation-as-a-gold-member
[3] https://rustfoundation.org/members/
[4] https://nerds.xyz/2026/03/canonical-rust-foundation/
Has there been... (Score:2)
Has there been an "unfortunate smelting incident?"
Rust could be awesome. (Score:5, Insightful)
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.
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)
I am using Rust for over 10 years, since version 1.0, and it delivers, regardless of various social dramas around it. Besides, from my experience, the majority of "religious zealots" are actually the ones attacking the language and the community, which is, by the way, very friendly.
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:1)
Exactly. It's a good language. It solves obvious and recurring problems that plague C/C++. It produces fast code and it is used from application level all the way down to the kernel. I wouldn't advise rewriting any code for the sake of it unless what was there was an unmaintainable or incredibly fragile mess that needed rewriting. However for new code that previously would have used C/C++ the question should be - why shouldn't I write it in Rust? Maybe there are reasons, but the default these days for anybo
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)
> 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?
Rust and AI are trying to solve the wrong problem (Score:2)
A programming language is a language that you use to explicitly describe what you want a computer to do. If you can't describe what you want the computer to do no amount of AI or new fangled language will help. I sort of liked Rust over C in that it stops idiots from doing stupid things (and smart people from accidentally doing dumb things) but in the end all it does is makes the idiots slightly harder to spot. You and your company actually need to sit down and figure out what you want before hammering
a corporation gave some money... (Score:5, 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)
You''ve added the word 'more' here and that wasn't in the original statement. The original statement is 100% correct. It would also be correct for Java, Javascript , C#...but it's still correctly used here.
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)
>> 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."
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:2)
> The difference is that everything is statically linked in Rust.
That's not correct: Rust [1]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.
[1] https://medium.com/@jesuskevin254/dynamic-vs-static-linking-in-rust-a-practical-guide-15b720864369
Ada Redux (Score:1)
Back in the 80s, Ada was the latest greatest thing, and was going to replace everything. It was a pretty great language (memory safety, ...... ) but what killed it was the poor implementation of the library support structure. Too many unnecessary recompiles were triggered -- big projects with superfast special-build Ada compile computer just couldn't keep up -- the build never finished unless all development paused too. Pascal was a toy language, C++ was a chaotic churn, so what was left? Yup, C it was. ;^
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