Message-ID: <aab4312f-67dc-4fc8-ae5a-59b5933aa220@ralfj.de>
Date: Tue, 4 Mar 2025 19:24:14 +0100
From: Ralf Jung <post@...fj.de>
To: Ventura Jack <venturajack85@...il.com>
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)

Hi all,

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

It was an accident. We have an established process for making such changes while 
keeping the ecosystem impact to a minimum, but mistakes were made and so the 
ecosystem impact was beyond what we'd be willing to accept.

The key to understand here that there's a big difference between "we do a 
breaking change but hardly anyone notices" and "we do a breaking change and 
everyone hears about it". The accident wasn't that some code broke, the accident 
was that so much code broke. As you say, we have minor breaking changes fairly 
regularly, and yet all the examples you presented of people being upset were 
from this one case where we screwed up. I think that shows that generally, the 
process works: we can do minor breaking changes without disrupting the 
ecosystem, and we can generally predict pretty well whether a change will 
disrupt the ecosystem. (In this case, we actually got the prediction and it was 
right! It predicted significant ecosystem breakage. But then diffusion of 
responsibility happened and nobody acted on that data.)

And yes, *technically* that change was permitted as there's an exception in the 
stability RFC for such type ambiguity changes. However, we're not trying to be 
"technically right", we're trying to do the right thing for the ecosystem, and 
the way this went, we clearly didn't do the right thing. If we had just waited 
another 3 or 4 Rust releases before rolling out this change, the impact would 
have been a lot smaller, and you likely would never have heard about this.

(I'm saying "we" here since I am, to an extent, representing the Rust project in 
this discussion. I can't actually speak for the Rust project, so these opinions 
are my own. I also was not involved in any part of the "time" debacle.)

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

There exist corner cases where that is true, yes. They are quite rare. Congrats 
on finding one! But you hardly ever see such examples in practice. As above, 
it's important to think of these things quantitatively, not qualitatively.

Kind regards,
Ralf

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