Linux Kernel Prepares Rust Toolchain Upgrade To v1.71

[moltonel]

I would love for the language to have some kind of LTS releases, as a maintained target that doesn't change in a number of years

Maybe you'd be interested in Ferrocene, they are certifying rustc and will presumably provide LTS-like maintenance. There's also a community desire to apply at least security fixes to older releases, we "just" need somebody to do this job reliably.

In some ways, rustc's high quality assurance and backward compatibility make an LTS less desirable: why do the extra work of backporting fixes when users can fearlessly use the latest compiler, or use their adequate old version ? I know there are justified use-cases, they're just less common than what other languages have trained us to think.

More to be able to both have a named "curriculum" to study the language and for alternative implementations to target (i.e. the gcc rust implementation, so that it doesn't have to chase a fast moving target).

I don't really see the value in this. An alternate implementation can easily choose a specific rustc version to emulate. That's what gccrs is currently doing, by having rustc 1.49 as its first milestone target (although they do cherry pick features from newer rust versions, and can plan ahead a bit). An LTS wouldn't help for this.

Keep in mind the desire for an LTS is niche, and that alternate implementations are contentious. Very few rust dev care about remaining compatible with a year-old rustc, let alone gccrs. Crates bump their MSRV pretty quickly. What good is a compiler that can only compile half of the ecosystem ?

[Antartica]

No, the fix was not adding an `Eq` trait nor switching to `.first()` methods, those changes were added in passing, probably suggested by the Rust linter.

The actual fix was to specify which trait to use for the `::MAX` associated constant. The library defines its own trait and constant, but Rust 1.70 added `::MAX` to the nonzero types, so there was now an ambiguity. While adding a trait method or constant that name-collides with existing code is technically a breaking change, it's not one that can be reasonably prevented, and any language that allows defining symbols in the same namespace (before disambiguation) as its stdlib is subject to it. In this case, `::MAX` already existed for all the primitive integers, so it's completely normal and expected that it got added to `NonZero*`. Mp4parse-rust could, in hindsight, have seen it coming.

Rust's backward is great, but it isn't absolute, just like C/C++/Python/Go/Java backward compatibility isn't absolute. There's a reason why distributions sometimes take months to update those compilers/runtimes: because they invariably cause some practical breakage that take time to resolve. Rust is arguably better than most on this metric, enabling distributions and developers to adopt new versions much faster than we can with gcc for example.

Thank you for the explanation. That makes a lot of sense, and it is hardly avoidable short of making the language not evolve.

OTOH rust is still evolving quickly as it finds more use and desirable features for those cases are added or incongruences are fixed, so arguably it has more opportunities for those clashes while it is still "young".

Anyway, I would love for the language to have some kind of LTS releases, as a maintained target that doesn't change in a number of years (hence more than the current numerically tagged releases, as it would have to be maintained). More to be able to both have a named "curriculum" to study the language and for alternative implementations to target (i.e. the gcc rust implementation, so that it doesn't have to chase a fast moving target).

[moltonel]

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.

No, the fix was not adding an `Eq` trait nor switching to `.first()` methods, those changes were added in passing, probably suggested by the Rust linter.

The actual fix was to specify which trait to use for the `::MAX` associated constant. The library defines its own trait and constant, but Rust 1.70 added `::MAX` to the nonzero types, so there was now an ambiguity. While adding a trait method or constant that name-collides with existing code is technically a breaking change, it's not one that can be reasonably prevented, and any language that allows defining symbols in the same namespace (before disambiguation) as its stdlib is subject to it. In this case, `::MAX` already existed for all the primitive integers, so it's completely normal and expected that it got added to `NonZero*`. Mp4parse-rust could, in hindsight, have seen it coming.

Rust's backward is great, but it isn't absolute, just like C/C++/Python/Go/Java backward compatibility isn't absolute. There's a reason why distributions sometimes take months to update those compilers/runtimes: because they invariably cause some practical breakage that take time to resolve. Rust is arguably better than most on this metric, enabling distributions and developers to adopt new versions much faster than we can with gcc for example.

[bug77]

Completely agree with that. Having the borrow checking in the compiler is a very nice feature to have, and one that should be considered in some extent in new languages. I'm eager to see what other approaches to have that feature other language designers use.

Alas, for my programming style, rust is not as a good fit, as professionally I'm into distributed systems and having the liberty of implementing each part in the best language for the problem makes me very wary of languages that aim to be everything for everybody. A lot of problems become trivial when the right language is chosen to tackle it, and then it becomes a matter of choosing the right boundary for IPC or defining the scope of the communication protocol.

I agree we agree

However, I would argue no language does everything for everybody. There are some languages that fit more than one purpose, but none can truly be classified as fit for everything. Python, Java, C# fit more than one purpose, for example, but none of them pretends to be a systems programming language. Web development also relies on a handful of languages, even though some will consider (pardon the expression) JavaScript fit for backend usage. Go is fit for backend development. And so on...

I agree 100% that picking the right tool/language for the job can make of break a project. The downside of using a different language for everything is that you need programmers that know all these languages and you cannot shuffle them around as work slows down in one area and picks up in another. And it's a pretty big downside, considering how difficult it has become to find good programmers even in widespread languages, like Java

[NobodyXu]

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.

That's certainly a problem, although I think Rust has been quite careful on this and the features set is mostly OK.

If anything, beginners are mostly scratching their heads on how to satisfy the borrow checker, once they understand how to use it others features are not that confusing to them.

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 do Rust programming and contributes to several different crates, some is asynchronous, some is more wrapping of syscalls/windows api to expose a platform-independent library, also contributed to arena crates, string with inline storage and etc, including tokio, and I don't think Rust has too many features.

It's true that there are a lot of features, but they can be split into two different parts: Ones that are mostly used in primitives libraries, like `unsafe`, `repr(*)`, `unsafe impl Send for ... {}`, trait, and ones used in application code/high-level, for example async, trait, etc.

And I think it's mostly ok on cognitive load on programmers, along with the accessible doc.

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

IMHO Gnome is written in C and firefox is a web browser, which is a very complex beast.

I don't think that reimplement is related to language, rather because their own goal/optimization/refactor or sheer complexity.

[NobodyXu]

Alas, for my programming style, rust is not as a good fit, as professionally I'm into distributed systems and having the liberty of implementing each part in the best language for the problem makes me very wary of languages that aim to be everything for everybody. A lot of problems become trivial when the right language is chosen to tackle it, and then it becomes a matter of choosing the right boundary for IPC or defining the scope of the communication protocol.

IMO Rust is not designed to be everything for everybody, it sits in high-performance and zero-cost niche, the same one as C and C++.
I don't see how it is trying to be everything for everybody, for example, it is explicit that it isn't for data engineer or people who just aren't into programming or dealing with borrow checker at all and can stand the cost of GC.

[Antartica]

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.

Completely agree with that. Having the borrow checking in the compiler is a very nice feature to have, and one that should be considered in some extent in new languages. I'm eager to see what other approaches to have that feature other language designers use.

Alas, for my programming style, rust is not as a good fit, as professionally I'm into distributed systems and having the liberty of implementing each part in the best language for the problem makes me very wary of languages that aim to be everything for everybody. A lot of problems become trivial when the right language is chosen to tackle it, and then it becomes a matter of choosing the right boundary for IPC or defining the scope of the communication protocol.

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

[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?

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