A passive-aggressive exit, but not unusual compared to other Rust drama.

> I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix

I wonder how much of the nontechnical reasons were actually technical.

> A passive-aggressive exit, but not unusual compared to other Rust drama.

By Linux kernel drama standards, it was a non-event.

You have the video segment in text, it was pretty non-technical. "NO! We don't want to encode what our assumptions are! We don't want to learn Rust. What do you mean write down our assumptions?"

Holy shit. It seems they are poisoning this effort on purpose. They are arguing against something the person isn't even saying.

That was a dramatic minute, of a 35 minute video. The rest of it, coupled with the behind-the-scenes, may paint another picture.

IMO, I sense a conflict of technical principles (or lack thereof) which manifests as social conflict. That pattern seems to come up in Rust; specification, async, etc.

Who was the angry guy who was shouting ?

Unless I'm mistaken, LWN suggests it's Ted Ts'o

https://lwn.net/Articles/978738/

Ted's objection is perfectly reasonable, and the way that Linux works and has always worked internally. If an internal (not userspace) API changes then code that uses that API has to be fixed. He also quite reasonably says that it'll take time to understand the trade-offs of encoding constraints into the type system.

Bringing out silly and absurd strawmen attacks like "you're trying to convince everyone to switch over to the religion as promulgated by Rust" is anything but "perfectly reasonable".

maybe. but is it really FALSE?

anyway, the point of the resignation is not wanting to deal with all this, not necessarily taking a side, so I’m not even disagreeing with you. But obviously, it is a disagreeable atmosphere. I don’t find that debatable, even if that’s due to people feeling paranoid about a (nonexistent?) rust religious takeover.

I think we can all admit Rust definitely has its ideologues and cult acolytes.

Yes, it's really false. They weren't saying that maintainers couldn't change the API nor that the maintainers who changed the API had to update the Rust part, just that they needed to tell the Rust maintainers what they did and what they intended so that they could correctly encode their underlying assumptions in code.

In other words, they simply requested adequate documentation and the response was "I'M NOT LEARNING RUST AND YOU CAN'T MAKE ME", effectively. That is nontechnical nonsense

> They weren't saying that maintainers couldn't change the API nor that the maintainers who changed the API had to update the Rust part

So maintainer would have to either wait for Rust team to update their API or learn Rust.

Seems like an unnecessary dependency.

Yes, the burden on the C maintainers is low but not zero. In a shared project, other people matter too. If you don't like it you should just work on solo projects.

The religion known as C-ism is sabotaging Linux.

Not really, as the only point he made wasn't under discussion or in conflict at all. The bulk of the words he said were intended to deliver other messages. I took the time to explain it in some detail here: https://news.ycombinator.com/item?id=41396677

It's deeply ineffective engineering communication. Below a professional standard.

The Phoronix forums are always a place of infinite brain rot. Phoronix is valuable, but its forums... No.

There's someone saying they need Microsoft people like they need fleas. Ts'o works at Google, so it doesn't really make any sense.

the maintainer who left linux is employed by MSFT

And Ts'o works at Google.

I'm out of my depth here, and I don't fully understand. From what I gather, Rust restricts the possible pathways in the problem space to ensure certain assumptions in the API and to manage memory safely. Is the issue that C allows for more freedom in exploring all possible pathways, or is the problem rooted only to cultural or else?

My understanding is the Linux kernel devs are refusing to explain the API and put it down in writing with clear documentation on what the contract is, and then they further gaslight and twist the situation with messaging like "you're trying to convince everyone to switch over to the religion as promulgated by Rust" (direct quote from a Kernel dev). Basically the worst of the worst behavior.

Have you considered trying to understand the perspectives of people in the C kernel dev camp? This seems awfully biased towards a hermeneutic of “C developer bad, Rust developer good”.

I'm a C developer. What I see from some in the C kernel dev camp is a refusal to participate, and further an active attempt to stonewall progress. The Rust devs have been highly accommodating in every possible way, but that's just not enough for them.

It seems to me that C and Rust approach library APIs with different mindsets.

Warning: lots of stereotypes follow.

Rust believes APIs should be [close to] impossible to use incorrectly. So we get rich type system, contracts, and other kinds documentation. All corner cases are either impossible because of the type or explicitly written down in the contract. If UB happens because user wrote incorrect code, that's a library's bug because it did not defend against it.

C believes the programmer. Documentation typically mentions happy path and some popular errors only. Lots of assumptions are implicit, like thread-safety, reentrance, (lack of) NULLs, lifetimes of inputs/outputs. It's up to the user of the library to figure out restrictions if their usecase is not in the documentation. Common sense and knowledge of C traditions helps. If UB happens because the user did something a bit out of the usual, it's on the user.

That brings us to different mindsets of library developers.

In Rust you typically write code while proving that it's correct in all theoretically possible cases, otherwise the code does not even compile. If it becomes too hard, you refactor API, possibly making the implementation harder. But your API is kind of nice in the kind.

In C you take whatever piece of code you found to be useful, extract it in a function or two and use in the project. If you happen to need that exact code somewhere else, you use it. There is no need to prove that the code always works or that it's a sound abstraction. If it works, it works. If it stops working in some case because of a bad API design, then you decide whether it's worth refactoring or not. That makes the initial implementation simpler, but it lacks contracts by design.

So I attribute it to cultural differences between "C programmers" and "Rust programmers". For Rust programmers, "full function contract" is a must, so documenting it seems easy. For C programmers, "full function contract" is not required for writing working code in 95% of cases, so documenting it is extra chore with no benefit.

imagine the semantic malebolge that would emerge if they used C++ in the kernel. It would be a nightmare if not managed carefully.

The problem as I see it is that maintaining two API languages implies that one must always “chase” the other if the primary language is refactored. In a single-language codebase, a single refactor can fix all of the related code more easily, unless the maintainer is an expert in both.

Comments moved to https://news.ycombinator.com/item?id=41387924.