Message-ID: <CAFJgqgRFEvsyf9Hej-gccSdC-Ce8DbO5DgHatLoJ-aYi1_ZcyA@mail.gmail.com>
Date: Fri, 28 Feb 2025 13:41:05 -0700
From: Ventura Jack <venturajack85@...il.com>
To: Ralf Jung <post@...fj.de>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>, 
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Gary Guo <gary@...yguo.net>, 
	torvalds@...ux-foundation.org, airlied@...il.com, boqun.feng@...il.com, 
	david.laight.linux@...il.com, ej@...i.de, gregkh@...uxfoundation.org, 
	hch@...radead.org, hpa@...or.com, ksummit@...ts.linux.dev, 
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)

On Thu, Feb 27, 2025 at 12:45 PM Ralf Jung <post@...fj.de> wrote:
>
> Hi,
>
> >>> If C was willing to break code as much as Rust, it would be easier to
> >>> clean up C.
> >>
> >> Is that true? Gcc updates do break code.
> >
> > Surely not as much as Rust, right? From what I hear from users
> > of Rust and of C, some Rust developers complain about
> > Rust breaking a lot and being unstable, while I instead
> > hear complaints about C and C++ being unwilling to break
> > compatibility.
>
> Stable Rust code hardly ever breaks on a compiler update. I don't know which
> users you are talking about here, and it's hard to reply anything concrete to
> such a vague claim that you are making here. I also "hear" lots of things, but
> we shouldn't treat hear-say as facts.
> *Nightly* Rust features do break regularly, but nobody has any right to complain
> about that -- nightly Rust is the playground for experimenting with features
> that we know are no ready yet.

I did give the example of the time crate. Do you not consider
that a very significant example of breakage? Surely, with
as public and large an example of breakage as the time crate,
there clearly is something.

I will acknowledge that Rust editions specifically do not
count as breaking code, though the editions feature,
while interesting, does have some drawbacks.

The time crate breakage is large from what I can tell. When I
skim through GitHub issues in different projects,
it apparently cost some people significant time and pain.

    https://github.com/NixOS/nixpkgs/issues/332957#issue-2453023525
        "Sorry for the inconvenience. I've lost a lot of the last
        week to coordinating the update, collecting broken
        packages, etc., but hopefully by spreading out the
        work from here it won't take too much of anybody
        else's time."

    https://github.com/NixOS/nixpkgs/issues/332957#issuecomment-2274824965
        "On principle, rust 1.80 is a new language due
        to the incompatible change (however inadvertent),
        and should be treated as such. So I think we need
        to leave 1.79 in nixpkgs, a little while longer. We can,
        however, disable its hydra builds, such that
        downstream will learn about the issue through
        increased build times and have a chance to step up,
        before their toys break."

Maybe NixOS was hit harder than others.

If you look at.

    https://github.com/rust-lang/rust/issues/127343#issuecomment-2218261296

It has 56 thumbs down.

Some Reddit threads about the time crate breakage.

    https://www.reddit.com/r/programming/comments/1ets4n2/type_inference_breakage_in_rust_180_has_not_been/

        "That response reeks of "rules for thee, but
        not for me" ... a bad look for project that wants
        to be taken seriously."
    https://www.reddit.com/r/rust/comments/1f88s0h/has_rust_180_broken_anyone_elses_builds/

        "I'm fine with the Rust project making the call that
        breakage is fine in this case, but I wish they would
        then stop using guaranteed backwards compatibility
        as such a prominent selling point. One of the most
        advertised features of Rust is that code that builds
        on any version will build on any future version
        (modulo bugfixes). Which is simply not true (and
        this is not the only case of things being deemed
        acceptable breakage)."

Some of the users there do complain about Rust breaking.
Though others claim that since Rust 1.0, Rust breaks very
rarely. One comment points out that Rust is allowed to
break backwards compatibility in a few cases,
according to its pledge, such as type inference changes.
This does not refer to Rust editions, since those are
clearly defined to have language changes, and have automated
tools for conversion, and Rust projects compile against
the Rust edition specified by the project independent
of compiler version.

rustc/Rust does have change logs.

    https://releases.rs/

and each of the releases have a "Compatibility Notes"
section, and in many of the GitHub issues, crater is
run on a lot of projects to see how many Rust libraries,
if any, are broken by the changes. Though, for bug fixes
and fixing holes in the type system, such breakage
I agree with is necessary even if unfortunate.

> > Rust does admittedly a lot of the time have tools to
> > mitigate it, but Rust sometimes go beyond that.
> > C code from 20 years ago can often be compiled
> > without modification on a new compiler, that is a common
> > experience I hear about. While I do not know if that
> > would hold true for Rust code. Though Rust has editions.
>
> Well, it is true that Rust code from 20 years ago cannot be compiled on today's
> compiler any more. ;)  But please do not spread FUD, and instead stick to
> verifiable claims or cite some reasonable sources.

Sorry, but I did not spread FUD, please do not accuse
me of doing so when I did not do that. I did give an
example with the time crate, and I did give a source
regarding the time crate. And you yourself acknowledge
my example with the time crate as being a very significant
one.

> > The time crate breaking example above does not
> > seem nice.
>
> The time issue is like the biggest such issue we had ever, and indeed that did
> not go well. We should have given the ecosystem more time to update to newer
> versions of the time crate, which would have largely mitigated the impact of
> this. A mistake was made, and a *lot* of internal discussion followed to
> minimize the chance of this happening again. I hope you don't take that accident
> as being representative of regular Rust development.

Was it an accident? I thought the breakage was intentional,
and in line with Rust's guarantees on backwards
compatibility, since it was related to type inference,
and Rust is allowed to do breaking changes for that
according to its guarantees as I understand it.
Or do you mean that it was an accident that better
mitigation was not done in advance, like you describe
with giving the ecosystem more time to update?

>

Another concern I have is with Rust editions. It is
a well defined way of having language "versions",
and it does have automated conversion tools,
and Rust libraries choose themselves which
edition of Rust that they are using, independent
of the version of the compiler.

However, there are still some significant changes
to the language between editions, and that means
that to determine the correctness of Rust code, you
must know which edition it is written for.

For instance, does this code have a deadlock?

    fn f(value: &RwLock<Option<bool>>) {
        if let Some(x) = *value.read().unwrap() {
            println!("value is {x}");
        } else {
            let mut v = value.write().unwrap();
            if v.is_none() {
                *v = Some(true);
            }
        }
    }

The answer is that it depends on whether it is
interpreted as being in Rust edition 2021 or
Rust edition 2024. This is not as such an
issue for upgrading, since there are automated
conversion tools. But having semantic
changes like this means that programmers must
be aware of the edition that code is written in, and
when applicable, know the different semantics of
multiple editions. Rust editions are published every 3
years, containing new semantic changes typically.

There are editions Rust 2015, Rust 2018, Rust 2021,
Rust 2024.

Best, VJ.

Powered by blists - more mailing lists