Re: C aggregate passing (Rust kernel policy)

[Kent Overstreet <kent.overstreet@linux.dev>]

On Thu, Feb 27, 2025 at 10:18:01PM +0000, David Laight wrote:
> On Thu, 27 Feb 2025 15:22:20 -0500
> Kent Overstreet <kent.overstreet@linux.dev> wrote:
> 
> > On Thu, Feb 27, 2025 at 08:45:09PM +0100, Ralf Jung 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.  
> > 
> > It's also less important to avoid ever breaking working code than it was
> > 20 years ago: more of the code we care about is open source, everyone is
> > using source control, and with so much code on crates.io it's now
> > possible to check what the potential impact would be.
> 
> Do you really want to change something that would break the linux kernel?
> Even a compile-time breakage would be a PITA.
> And the kernel is small by comparison with some other projects.
> 
> Look at all the problems because python-3 was incompatible with python-2.
> You have to maintain compatibility.

Those were big breaks.

In rust there's only ever little, teeny tiny breaks to address soundness
issues, and they've been pretty small and localized.

If it did ever came up the kernel would be patched to fix in advance
whatever behaviour the compiler is being changed to fix (and that'd get
backported to stable trees as well, if necessary).

It's not likely to ever come up since we're not using stdlib, and they
won't want to break behaviour for us if at all possible.