3K Lines Of New Rust Infrastructure Code Head Into Linux 6.13

[jacob]

Which part or subsystem of the Linux kernel would like the most to see adopt Rust?

Is it graphics device drivers? or the network stack? or is it file systems? ext4 or Btrfs or a brand-new one? Perhaps the CPU scheduler or the I/O scheduler?

Reportedly bcachefs is interested in moving towards Rust.

[jacob]

Funny enough, the overwhelming majority of people I see pointing to formal specification are C or C++ programmers arguing in bad faith because they see it as a threat to the perceived value of the skills they've tied their sense of self-worth to and just want to put roadblocks in the way.

Now, Rust getting specified to a level that C and C++ are not and never will never be because of politics between the various implementers? Yes, I'm all for that... but don't throw stones from glass houses swiss-cheese'd with holes labelled "implementation defined".

...especially when what the Linux kernel is currently written in (GNU C11 plus reliance on various GCC-specific ANSI C "implementation defined" decisions that Clang copied) isn't formally specified either.

I agree that the "standardisation" arguments are disingenuous, but more importantly they are a faux solution to a non existent problem. I firmly believe having programming languages defined by standards was indeed important in the 1980-1990s, when compilers were proprietary and closed. Sticking to something like ANSI C was a way for developers to avoid vendor lock-in, but even so, most nontrivial projects could really only be built with a particular compiler. It's still the case today, the Linux kernel itself can't basically be built using anything other than GCC (or Clang, since Clang expressly mimics GCC for that very reason).

Today it's expected that compilers would be open source and free (speech and beer), and Rust is open source and free. There is no risk of vendor lock in and the requirement for standardisation is moot. In fact, not only the fact of everyone always using the same compiler makes things easier and more interoperable, should someone hit a roadblock with rustc, in many cases it's actually easier to fix rustc than trying to move a multi-million LOC project to a hypothetical different compiler.

[jacob]

"Civilised" is british, very few people use it.

Actually most people use it: the whole of india (> 1 billion people), plus everyone from a non-English speaking country who learned English at school. They virtually always teach British English, not American English.

[Old Grouch]

Standards don't magically override human and/or corporate behaviour... but they do increase the risk of bureaucratic tarpits and cliques. (Plus, given the Rust v1.0 Stability Promise, the likely outcome is "Sorry, your standard may say X, but ten times as many crates would break if we stopped doing behaviour Y, so your standard is wrong"... which is why Rust prioritized a regression suite and a bot for running tests against large swaths of crates.io over a standard.)

I take your point about standards, and I'm fully aware of the issues so neatly encapsulated in the xkcd cartoon: xkcd: Standards. Platform specific extensions are a problem, certainly.

For reference: The Rust Stability promise.

I think we might agree that a formal specification, in the long run, could well be helpful.

Stability is indeed, wonderful, but only as long as the functionality that is stable is sufficient for the needs of people using the language - otherwise you end up with the situation described in the Stability Promise blog post:

First, as the web has shown numerous times, merely advertising instability doesn't work. Once features are in wide use it is very hard to change them -- and once features are available at all, it is very hard to prevent them from being used. Mechanisms like "vendor prefixes" on the web that were meant to support experimentation instead led to de facto standardization.

There's obviously a tension between what 'real world' users of a language want and what more academic/bureaucratic committee types might argue 'should' be in the language. If Rust finds a more useful way of managing that situation, then I will be very happy. Getting groups of people, each with their own agenda, to cooperate on things for long periods is hard. Constructive, insightful, and practical new thinking on how to do this is always welcome

[ssokolow]

There's obviously a tension between what 'real world' users of a language want and what more academic/bureaucratic committee types might argue 'should' be in the language. If Rust finds a more useful way of managing that situation, then I will be very happy. Getting groups of people, each with their own agenda, to cooperate on things for long periods is hard. Constructive, insightful, and practical new thinking on how to do this is always welcome

*nod* I should probably mention this relevant link:

https://rust-lang.github.io/rust-project-goals/2024h2/rfl_stable.html#the-next-six-months

TL;DR: The Rust team's "the next six months" plan is prioritizing stabilization for the nightly features the Rust support in the kernel currently depends on.

[oleid]

A (formal) specification and standard validation suite would be a good thing to have. The same would apply to any language used for (kernel) programming, and saying that Rust lacks a formal specification is not meant (by me) to imply that C (or C++) does.

You're probably happy to read that a specification is being worked on.

[oleid]

They virtually always teach British English, not American English.

Not true where I come from. They teach both. But to be fair, they start with Brittish English.

[Phoronos]

Actually most people use it: the whole of india (> 1 billion people), plus everyone from a non-English speaking country who learned English at school. They virtually always teach British English, not American English.

Not true anymore, it used to be true several decades ago.
But as of today, schools teach more and more american english and in the universities, it is american english which is mostly used.

[darkonix]

Exactly why I don't want Rust to have a standard in the mould of C or C++. Have you read about the state of the people steering C++? It's the worst "my idea is correct by definition, regardless of implementability or technical merits" clique you've ever heard of. Think "mean high school girl politics" but they're old men.

...plus, people really seem to have a skewed perception of what "having a standard" actually means for C or C++. People don't write ANSI C. They pick a compiler per platform they want to support (two if you're lucky) and write to the extensions that compiler offers because C and C++ as standardized are too incomplete for real-world use. That's what the Linux kernel does with GCC's "GNU C".

...and there are a ton of C compilers that just implement what they want and don't care.

I'm reminded of this quote:



Standards don't magically override human and/or corporate behaviour... but they do increase the risk of bureaucratic tarpits and cliques. (Plus, given the Rust v1.0 Stability Promise, the likely outcome is "Sorry, your standard may say X, but ten times as many crates would break if we stopped doing behaviour Y, so your standard is wrong"... which is why Rust prioritized a regression suite and a bot for running tests against large swaths of crates.io over a standard.)

Fan fact: any IBM source code line size limit of 72 characters in many of their operating systems can be traced back to punched cards limits in the '50s era: https://en.m.wikipedia.org/wiki/Punched_card

Don't ask me how I know.