Linux Kernel Prepares Rust Toolchain Upgrade To v1.71

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

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

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

[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

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

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

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 ?