Rust-for-Linux developer Wedson Almeida Filho drops out

Rust compilers work pretty damn well, even if they don't have the official tier 1 blessing.
I only hit a compiler bug once, so far. In a tier 3 architecture (esp32) a couple of years ago.

And it's not that all stable gcc versions support building the kernel.
The kernel history is *full* of gcc workarounds and banning some gcc versions from building the kernel.
That can easily be done with Rust as well. If there's a buggy version, just ban it. Or the other way around pin a known-good set of Rust compilers. (That's how it currently works, as far as I understand it). That has been done with gcc, too.

Based on that, I think arm32 should not be a blocker.

We need to apply the same basic rules for gcc, clang and Rust.

>SH enables wifi in the defconfig too.

Ok. Is that really a big thing? Should that block us? These are the questions I'd like to see.
And yes, the answer *can* be yes, if there are facts that show this.

>USB device support is probably pretty universal across architectures.

Yes. But IMO that doesn't mean we should support users who stick an USB host controller into an Alpha machine to put an USB wifi into it.

>saying "you were always against rust, so you just pretend you care about architectures"
>is the wrong way to go about this.

Yes, correct. This is wrong to say.

"you do" and "you just" sprinkled with "religion" and "you force me to..." is the biggest problem in this whole discussion. And it's also not limited to the kernel. I saw this exact same behavior in completely different contexts, too.
It's unprofessional.
We all need to calm down a bit and get back to talking about facts.

The unsafe block as such doesn't give you rights to violate rules.
It gives you access to deref of raw pointers, but you still have to adhere to the rules.
It does also give you access to some unsafe intrinsics, which might be what you need.
But you can't simply put an unsafe block around your data race and then hope it's fine. It's still a forbidden data race.
So you can for example use an unsafe atomic intrinsic to avoid the data race.

That's not the right way to think about it. "unsafe" lets you deference raw pointers, which means you can bypass the borrow checker by using raw pointers instead of references, but you can use references in unsafe Rust and they still get borrow-checked. This matters because it means that entering an unsafe block because e.g. you want to call a C function does NOT mean that you are suddenly also susceptible to lifetime bugs.

> Unsafe Rust is inevitable in the Linux kernel

It is inevitable that unsafe Rust is present in the kernel, but it matters a great deal *how much* is present and where it is present. If you have unsafe Rust in the Rust wrappers around kernel APIs but you can write a lot of drivers with zero unsafe Rust (which is actually the goal), then that is likely to be a big win. You write the wrappers, you invest effort in reviewing that code and testing it, and then all your driver code (which is much more code than the wrappers, in the long run if not the short run) benefits from the safe Rust guarantees.

OTOH if every driver has to use copious amounts of "unsafe" then Rust in the kernel will have failed.

> instead of something like Zig that has around 80% of the memory safety that you get from Rust's borrow checker feature set but with 0% of the downside of the loss of productivity in fighting the borrow checker?

In release builds (i.e. builds with acceptable performance) you get no use-after-free checking with Zig, and those are most of the exploited memory safety issues these days. Plus of course Rust is giving you more safety than just memory safety.

> I believe both Zig and Odin also do not have undefined behavior where Unsafe Rust and C do

UAF is for sure undefined behaviour in Zig. There is no way to define it!

> This strikes me as Zig 1.0 if the current trajectory holds true.

Nope, no UAF protection in production code with Zig.

I've never understood this argument. Saying "Rust is a bad choice for the kernel because you need unsafe sometimes" is the same as "C is a bad choice for the kernel because you need ASM blocks sometimes". Except nobody complains about the number of ASM blocks in the kernel.

It would be even worse if the option wasn't there. Then it would definitely have been a non-starter.

I'd hope their mission is to teach students the fundamentals that will make them effective at learning all the other technologies they'll need to use over their career, many of which haven't been invented yet, rather than training them in one specific language.

(The first language taught at my university was ML, specifically because it demonstrated the fundamentals of computation without all the distractions that C/Java/etc introduce, and because (being a practically useless language) it was unlikely any students had prior experience with it and everyone would start from a similar level. Then they taught maybe five other languages to varying extents, some more practical and some less.)

> There are literally hundreds of job postings for Rust while there are thousands for Go, or C, or Java, etc. (Indeed claims 400 currently. LinkedIn lists 300. Actual data.)

LinkedIn tells me there are 3000+ jobs for "Rust software engineer" in the US, so I'm not sure where you're getting 300 from. Certainly it's more niche than many other languages, but from an employability perspective it's not an extreme niche like e.g. Zig (4 jobs on LinkedIn).

For serious (non-blockchain) tech companies, Amazon alone has 173 job adverts that mention Rust - sometimes explicitly requiring Rust experience, though mostly asking for e.g. "Experience programming with at least one modern language such as Python, Ruby, Golang, Java, C++, C#, Rust". Knowing any of those will put you in a good position to learn the specific languages you need for the job. Microsoft has 97 mentioning Rust, e.g. "4+ years of experience with coding in one of C#, Python, Go, Rust, Java, C or C++", or "Knowledge/experience programming in RUST or other memory safe languages is highly desirable".

Google rarely mentions Rust in job adverts, but they've said over 1000 Google developers committed Rust code in 2022 and over 500 took a Google-developed training course. So I think that doesn't indicate they don't believe Rust experience is valuable, just that it's rare enough they don't bother calling it out in job ads, and they believe it's worthwhile to invest in training developers for their Rust-based projects, which could be seen as even stronger support than asking for prior experience.

And yet there are even more jobs that require JavaScript. Let's rewrite the kernel as a NodeJS module.

Rust will never be as popular as Go or Java, simply because it's not the best language for regular server-side applications.

And this comment embodies everything I think is WRONG with the current education system. That attitude belongs with the UK polytechnics of old, not what Universities are SUPPOSED to be for. Not blaming Universities, it's the politicians who are desperate to see everybody educated, when maybe the majority of people are incapable of benefiting from education!

What the parent has just described is what I would describe as TRAINING, not Education, and that does not belong in a traditional University. That's what Polytechnics did - they prepared people for the world of work, they trained them, and that's fine.

Going back to a study I came across, apparently the ability to think *logically* is acquired at about age 14, and maybe half of all people never acquire the ability. Yet education - higher education certainly - is all about logical thought! So why on earth are the politicians (I think this is the UK Conservatives pre Tony Blair, so that dates it) desperate to send half the population to Uni? It's coming home to bite them now, as a lot of people see Uni as loading them up with debt to acquire worthless qualifications. And for so many, that actually is the case.

Uni should be for education. Uni should be for teaching people how to use their brains. To quote a lady from years back on Radio 4 - "I didn't send my son to school to do Domestic Science so he could cook. I sent him to school to learn Latin so he knew how to read a recipe book and follow instructions". Too many people think education is doing Domestic Sci. IT ISN'T. THAT'S TRAINING. Education is learning Latin and Maths, so you can get a career as a programmer (like I did).

Cheers,
Wol

Thinking in terms of "(un)employable languages" is entirely the wrong way of thinking. Any CS graduate worth their salt is able to quickly pick up a new language and transfer the concepts they are familiar with -- that is what truly makes them employable.

> Then why is it so hard to understand what khim is actually saying?

Because English is a foreign language for khim? Of course it's more difficult to express yourself clearly (and/or succinctly) in a language that's not your native language. I can express my thoughts pretty fluently in Dutch; English is significantly harder, even though both languages are pretty closely related. French is almost hopeless even though our education system tried pretty hard making us learn that language. German is closer related still, but while I can read it a bit I can't write or speak it at all (other than trivial things like "Zwei Bier bitte"). If I try to express something in French, chances are French-speaking people will think it's difficult to understand too. And it's more difficult for things that are expressed differently in native versus foreign language.

How much study of Russian would you or I need before we are as proficient in it as khim is in English? Will khim wonder why he can't always understand our reasoning expressed in Russian?

I think you're thinking of the linguistic relativity, also known as the Sapir–Whorf hypothesis (and other terms), and more specifically it seems you're thinking of the strong form which says that language determines thought and that linguistic categories limit and restrict cognitive categories. Modern linguists don't accept that hypothesis anymore (or at least that stronger form).

You can express repetition in different programming languages in different ways.

What you're saying is: The representation matters, because different compilers/interpreters/programmers will understand different ways of representation.

What viro was saying (or at the very least, how I interpreted it): The representation doesn't matter, in the sense that any programming language can express repetition, and the choice is a simple consequence of the choice of programming language. It doesn't influence what concepts can be expressed in the different languages.

Law dictionaries exist to help ensure legal language is precise & unambiguous. There's a reason IETF requires two, independent implementations before declaring something a Internet Standard - https://www.ietf.org/participate/runningcode/implementati.... If two implementations don't produce the same product, it's time to go back and fine tune the specification to clarify the ambiguities that arise. And the only way to check for ambiguities is via an independent implementation.

"Heritage" is the usual respectful euphemism, I think?

Are you suggesting that a sample size of one that can't be corroborated is statistically or otherwise relevant?

Professors I engage with don't even think the language could be taught in a full academic year to upperclassmen.

Which sample size is more relevant when extrapolating to the general programmer?

I want to dive into this notion of "productive" and other philosophical tangents another time and another place but I want to leave this anchor out there:

How can you be productive in a language while at the same time, avoiding most of the features? Is that "productive"? Or is that, "I learned conditionals, assignment, and control flow" which is fundamental to operating in any language? It wouldn't take long to be "productive" in any sane language using those criteria and remaining within those confines. At what point can you say you've actually used a language? Can we measure this by percentage of the language that has actually been used? (This would clearly bias smaller languages like Lua but still.)

You're the second data point (along with Cyberax elsewhere in the comments) who brings up "strong C++ background" as a precondition for "easily picking up Rust". That does make a lot of sense, actually.

As a C programmer with a good working familiarity on kernel and low level topics, I see both C++ and Rust as something that would take a LOT of getting used to, they are both heavily resistant to casual lecture of sources one didn't spend a lot of time and thought writing themselves :)

I don't see "know c++ well" as an obvious required skill for a kernel hacker, so the point that kernel hackers in general would all have to take lengthy detours in order to pick up Rust still stands (unless they're already C++ experts, which would help, but presuming they are is unreasonable, because they're *kernel* hackers, not high-level code monkeys :)

Combine that with idiotic echoes like the one above and you have the exit survey for why I am likely not to renew.

This isn't an indictment of you, your team, or your choices in coverage but it is clear that I am not your target audience. Best of luck.

https://youtu.be/vB3ACXSesGo

And that process can even be turbocharged with tools like this:
https://crates.io/crates/bacon

Complicated and hard to understand compiler messages do exist in Rust, too. But they are very rare.

Yes, it takes a very long time to learn each and every detail of Rust.
But the same is true for C++ and even C itself.

But getting productive does not take weeks or months.

And learning Rust makes people better at programming in general.
Many concepts from Rust can be used in other languages, too. In fact, the kernel uses many of them already and many uses do predate Rust.
That reduces the step height for kernel developers even further.

I think it's much harder to come from the OOP-language side than from the C side when learning Rust, because OOP-thinking (inheritance) does not really work in Rust.

Either way, best of luck with all the work! We're all thankful for what you do! IOMMUFD is neat!

That actually might be a great idea. He had one of this pauses during the introduction of git, after the BitKeeper fiasco.

https://docs.kernel.org/kbuild/llvm.html#supported-archit...

And rust says:

https://docs.kernel.org/rust/arch-support.html

whereas the list of all architectures is currently

alpha, arc, arm, arm64, csky, hexagon, loongarch, m68k, microblaze, mips, nios2, openrisc, parisc, powerpc, riscv, s390, sh, sparc, um, x86, xtensa

So for something sufficiently core, you can't use rust.

I'm sure this will become better over time, but (IMHO) until it does there's a lot of stuff that's simply out of scope as I described.

Perhaps with the graphics driver(s?), NVMe driver and other things that have happened we should declare the rust experiment a success, and start focusing on the architecture story etc. (gccrs, code gen, whatever) so there can be hard dependencies. The extra dependency will probably still be hated by some (including some distributors perhaps), but at least it won't be a dependency that's literally impossible to satisfy.

I guess I just don't think it's fair to say it's all the fault of kernel maintainers, who are generally already overworked, have to support stuff on all architectures, have to (willing or not) learn a whole new thing, and then everyone says "oh but it works well for me so they're just being idiots." I mean, I guess we're used to being the scapegoats but still ... Both sides would do well with some empathy for the other side.