Linux Kernel Prepares Rust Toolchain Upgrade To v1.71

[jacob]

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.

But that's a nightly tool chain, isn't it?

[Antartica]

But that's a nightly tool chain, isn't it?

Uh? AFAIK, 1.63, 1.64 and 1.71 are stable releases. Nightlies are supposedly tagged with the date, aren't they?.

[bug77]

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.

You linked to a web search that doesn't show anything pointing at Rust breakage. By your own admission, the problem was in a library, yet you you point your finger at Rust.

NB Hypothetically speaking, if undefined behavior becomes defined at some point and the compiler starts rejecting it, that doesn't mean it used to work before. But I am not aware of previous undefined behavior in Rust, the very reason features are incubated first is to make sure everything is defined and works as expected.

[wswartzendruber]

There's a lot less Derp in this thread than there is most other Rust threads here.

I remember getting really turned off by Rust a couple of years back. It had something to do with default blanket trait implementations not allowing me to implement IntoIterator<> for my custom type. The Rust compiler needed to support something called specializations for that to happen, but it hadn't even been proven that it could be done in a sound manner.

I think this is the issue I encountered: https://github.com/rust-lang/rust/issues/20400

And on specialization: https://github.com/rust-lang/rust/issues/31844

Anyway, I've got back to C# and writing for .NET Standard.

[Antartica]

You linked to a web search that doesn't show anything pointing at Rust breakage. By your own admission, the problem was in a library, yet you you point your finger at Rust.

NB Hypothetically speaking, if undefined behavior becomes defined at some point and the compiler starts rejecting it, that doesn't mean it used to work before. But I am not aware of previous undefined behavior in Rust, the very reason features are incubated first is to make sure everything is defined and works as expected.

Sorry, I just wanted to show the error text, the fact it was a link was because I hastily took it from the browser history.

Yes, I assume that it was something about undefined behavior that later was better specified. OTOH, that it was in a library is moot. The problem is it didn't compile. Just for completeness, I have searched again the error, and found a nicely done bug report with a fix for freebsd:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271797

In the end, it was solved by making the compiler implement some traits using derive. But I'm at a loss why it compiled with older versions of rust.

Anyhow, you have to understand that rust in one more tool. There have been countless languages, and some that fizzled after a great initial enthusiasm (i.e. Scala). Personally I think rust is going the path of C++, incorporating as much features as it can, and I think that is wrong. I prefer using several languages with a razor-sharp purpose than a one-fits-all language, as that makes it easier to reason about the expected behavior of the code.

In the end, I'm sure other languages will incorporate the borrowing concept, as it has been done previously with optionals, errdefer, coroutines et al., and that is good as the state of the art advances.

[NobodyXu]

Anyhow, you have to understand that rust in one more tool. There have been countless languages, and some that fizzled after a great initial enthusiasm (i.e. Scala). Personally I think rust is going the path of C++, incorporating as much features as it can, and I think that is wrong. I prefer using several languages with a razor-sharp purpose than a one-fits-all language, as that makes it easier to reason about the expected behavior of the code.

TBF, sometimes including more features is definitely necessary and worth-while.

For example, having async in Rust is definitely a huge improvement than writing state machine manually and I am looking forward to having `yield` in Rust for generator/iterator.

Many language features is justified by existing features, P.S. we already have generics, so it makes sense to try adding specialisation, although this is quite complicated and will never land as-is.

There are also features requested because people need it, for example, the ability to have linear type for io-uring where a future is guaranteed to be dropped, thus making it possible to borrow a buffer instead of passing an owned buffer.

[Antartica]

TBF, sometimes including more features is definitely necessary and worth-while.

For example, having async in Rust is definitely a huge improvement than writing state machine manually and I am looking forward to having `yield` in Rust for generator/iterator.

Yes, definitely there are cases that justify adding more features, but doing so has a cost. In the end you can have a language so expansive that you can assume an average programmer doesn't know the language in its entirety, and that is a big problem for maintainable code.

It's not that you understand your own code, but that you can understand other people's code. If not, you enter a dynamic where "new recruits" are always deleting and reimplementing code instead of fixing the one already there, just because it uses some not-very-common features of the language. And then you lose tested code and program-features on the way (I see that a lot in gnome or in firefox; the amount of code they reimplement is staggering and a lot of features drop by the wayside).

[bug77]

Sorry, I just wanted to show the error text, the fact it was a link was because I hastily took it from the browser history.

Yes, I assume that it was something about undefined behavior that later was better specified. OTOH, that it was in a library is moot. The problem is it didn't compile. Just for completeness, I have searched again the error, and found a nicely done bug report with a fix for freebsd:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271797

In the end, it was solved by making the compiler implement some traits using derive. But I'm at a loss why it compiled with older versions of rust.

Thanks for the explanation.
I see no comments about implementing traits in either 1.07 or 1.71, but I do see a reference to impl_mul! which I can't find anywhere. My guess is the code used this macro which is either unstable or not from the standard crates. Thus, it wasn't the language itself at fault.
That said, Rust is still written by humans, so I can imagine something like that slipping by on occasion.

Anyhow, you have to understand that rust in one more tool. There have been countless languages, and some that fizzled after a great initial enthusiasm (i.e. Scala). Personally I think rust is going the path of C++, incorporating as much features as it can, and I think that is wrong. I prefer using several languages with a razor-sharp purpose than a one-fits-all language, as that makes it easier to reason about the expected behavior of the code.

Which is why I have always said using device drivers as a proving ground for Rust was a brilliant idea. A driver is a (mostly) self-contained piece of code. If it works, great, if it doesn't, don't include it. The kernel itself is fine either way. I am not for Rust-ing the kernel right away, but I do see how the kernel would be safer if Rust proved to be up to the task in the future.

In the end, I'm sure other languages will incorporate the borrowing concept, as it has been done previously with optionals, errdefer, coroutines et al., and that is good as the state of the art advances.

Yup, I've said this before, too: even if Rust doesn't become the next systems programming language, it's hard to imagine a language that does, if it doesn't at least borrow the idea of a borrow checker.

In a nutshell, there are still milestones Rust has to hit before becoming the next systems programming language. But so far, it has hit all the milestones it was supposed to, so at least to me it looks like it's on the right path.

[bug77]

Yes, definitely there are cases that justify adding more features, but doing so has a cost. In the end you can have a language so expansive that you can assume an average programmer doesn't know the language in its entirety, and that is a big problem for maintainable code.

It's not that you understand your own code, but that you can understand other people's code. If not, you enter a dynamic where "new recruits" are always deleting and reimplementing code instead of fixing the one already there, just because it uses some not-very-common features of the language. And then you lose tested code and program-features on the way (I see that a lot in gnome or in firefox; the amount of code they reimplement is staggering and a lot of features drop by the wayside).

Well, then we go back to ASM. Few things are more expressive than that.

Of course adding features has a cost (unrelated, but it's one of the reasons I like Go - include as little as possible to get the job done), this is a balance game. As such, it is futile to try to define what the right amount of features is or where the balance should lay. That's inherently subjective.

But as a thought experiment: you have one developer who doesn't know threading very well. Would you rather have them use async/await without understanding very what they do, or rely on them not using that and nailing the necessary callbacks on their own?

[Antartica]

But as a thought experiment: you have one developer who doesn't know threading very well. Would you rather have them use async/await without understanding very what they do, or rely on them not using that and nailing the necessary callbacks on their own?

Traditionally that has been solved successfully giving that developer a higher-level library specifically done for his/her needs that internally uses those features but exposes something he/she can understand. It is true that consumes time of your senior developers, but you have to be patient for the whole team to get up to speed with the features of the language(s) selected for the project.