Linux Kernel Prepares Rust Toolchain Upgrade To v1.71

[bachchain]

Rust is now 8 years old and still doesn't support the basic features e.g. Firefox needs in a stable manner.

What are you talking about?

https://firefox-source-docs.mozilla.org/writing-rust-code/update-policy.html

Official builds
We ship official stable Firefox with a stable Rust.

A pessimist might argue that it could take years before the language stabilizes enough.

Would you prefer the Python and Java approach where half the stdlib is either deprecated or unfinished because everything gets stabilized before it's ready? I would also remind you that C is over 50 years old at this point and still gets major revisions.

[Antartica]

What are you talking about?

https://firefox-source-docs.mozilla.org/writing-rust-code/update-policy.html

I've been recently bitten by this. I wanted to compile firefox-esr in debian 12, and the rust compiler I had installed was 1.64, from the last time I had to do some work in rust. It failed. I rustup'd and tried again with rust 1.71, it failed again.

In the end, it compiled with rust 1.63 (of course it did, as that is the version of rust packaged for debian 12, so firefox-esr sources from debian 12 had to compile with that), but the experience left me with a very bad aftertaste of the rust tooling. Surely I'm a lot less inclined now to use rust in projects that I intend to support for years.

[muncrief]

Rust and Python are chronically unstable languages and should never be used in mission critical projects, especially something like the Linux kernel that so many companies and individuals depend upon.

[darkonix]

Rust and Python are chronically unstable languages and should never be used in mission critical projects, especially something like the Linux kernel that so many companies and individuals depend upon.

Microsoft, Google and Amazon seem to think differently about rust. And Linux doesn't seem to have a problem with the experimental support in the kernel though it is too early to say. But what does python has to do with a kernel? It is not a systems language and no one is using as such.

[muncrief]

Microsoft, Google and Amazon seem to think differently about rust. And Linux doesn't seem to have a problem with the experimental support in the kernel though it is too early to say. But what does python has to do with a kernel? It is not a systems language and no one is using as such.

I understand that many disagree with my evaluation of Rust, and I included Python not because it's used in the kernel, but simply because it is equally unstable and unconcerned with backwards compatibility.

[bug77]

I understand that many disagree with my evaluation of Rust, and I included Python not because it's used in the kernel, but simply because it is equally unstable and unconcerned with backwards compatibility.

Ah, that makes sense, you don't know Rust. Rust is backwards compatible, whatever worked in Rust 1.0, still works in Rust 1.71.

[jacob]

What is it about this specific point that causes people to forget how to read? The exact same comment happens every single time Linux oxidation is mentioned, even when it's specifically addressed in the article.

They don't want to read. They just want to rant and whine that it's not 1972 any more.

[luno]

I've been recently bitten by this. I wanted to compile firefox-esr in debian 12, and the rust compiler I had installed was 1.64, from the last time I had to do some work in rust. It failed. I rustup'd and tried again with rust 1.71, it failed again.

In the end, it compiled with rust 1.63 (of course it did, as that is the version of rust packaged for debian 12, so firefox-esr sources from debian 12 had to compile with that), but the experience left me with a very bad aftertaste of the rust tooling. Surely I'm a lot less inclined now to use rust in projects that I intend to support for years.

Debian's traditional approach to software packaging may no longer be sufficient for many desktop users. Many desktop applications are updated more frequently than Debian's stable releases can accommodate. This can lead to outdated software and compatibility issues. I recently tried Debian 12, even neovim was outdated. forget about all Rust based tools like Helix, Zellij and others. Chromium is adding Rust as dependency so Debian should maybe move from old is best to stable is better. As a software developer, I sometimes want to use a license that disallows the shipping of old versions of my software that have been fixed in my recent stable releases. This is because I want to ensure that my users are always using the latest and most secure version of my software.

I like it in Server side but I am slowly moving away from it.

[DrYak]

Debian's traditional approach to software packaging may no longer be sufficient for many desktop users. {...} I like it in Server side but I am slowly moving away from it.

Debian "Stable" is targetting mainly server and other LTS-/ESR- type scenarios. To have more recent desktop experience, use "Testing" (which is also what Ubuntu is derived from) - it's supposed to be continuously updated (until the next freeze of stable). "Unstable" is the "guaranteed to break" that you should be weary of.

(Though personally, I tend to go instead to rolling distros: OpenSUSE Tumbleweed, and Arch derivative, e.g., Manjaro ARM and more recently SteamOS 3)

[Antartica]

Ah, that makes sense, you don't know Rust. Rust is backwards compatible, whatever worked in Rust 1.0, still works in Rust 1.71.

That is the theory. But the rust developers may find situations considered valid in past versions that might break some assurances of rust, and fixing those problems can make old code to not be able to compile in newer versions of the compiler. Moreover fixing that code might be non-trivial.

The case I mentioned earlier (that firefox-esr from debian 12 fails to compile with rust 1.64 and rust 1.71 but compiles with rust 1.63) boils down to this error:

error[E0277]: the trait bound `u64: Mul<NonZeroU8>` is not satisfied

Investigating that, I see that the mp4parse library had that problem, and the fix required adding classes (so it is a non-trivial fix).

So the assumption that newer rust releases are able to compile old code is not true for this version of firefox-esr.