Retiring from the Rust for Linux Project – Wedson Almeida Filho

A short resignation email on a mailing list is about as little drama as I can imagine for, well, resigning. Perhaps by "drama" you're referring to the linked video, but watching the clip, the only drama I see is accusations like "You're trying to convince everyone to switch over to the religion as promulgated by Rust." Regardless of the technical issues, that's an ad hominem with zero technical merit.

> You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other maintainers and contributors.

What change exactly is being imposed? Rust has been accepted, so that parts of the kernel can be written in either Rust or C. Nobody is pushing for an entire kernel rewrite in Rust. Nobody is pushing out C maintainers.

> The Rust minority has, as of yet, failed to properly answer what happens when C APIs change in either signature or semantics, either of which can break the Rust bindings.

He answers in the very video: there is a process and it is communication. When a C API change which can break the Rust bindings, you email the maintainer responsible for the Rust bindings. It's as simple as that.

> If broken bindings indeed can hold back changes, then C changes are held back by Rust and indeed then the onus is on the committer to either forego improving/evolving the C API or pick up Rust and fix the bindings also. In that case, yes, the Rust bindings will either freeze the C API or force the individual contributor to learn Rust.

This is already happening with C development anyway, when an API change causes drivers maintained by different people to be updated, but nobody is saying "C changes are held back by C".

> That people repeat their concerns isn't an expression of stupidity any more than a result of the people driving Rust into the kernel have yet to properly communicate how they envision this process to work, I suppose.

But in this video, you see someone driving Rust into the kernel communicating how they envision this process to work, and a guy adopting a hostile tone claiming to be an engineer and calling another language a religion. This isn't concern, this is discrimination.

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.

I have watched the video.

I am not ignoring or denying there isn't individuals throwing their toys out of the pram when follow-up discussions should remain respectful and mature.

On one end, I get it. Linux kernel is a BIG project. I assume it is still the biggest Free/Open Source project today. Many developers involved in this project genuinely care about it. These big projects will NOT go down well if a release contains bugs. By having another language in the equation is likely to cause tension especially code breakages. Now, these guys need to learn Rust! When a language like Rust is given a lot of push today I can understand their anger when it can feel like it is pushed into the kernel too soon too quickly.

I am not defending these guys - I am just saying I get it. However, on the other end, I do not want to see a project contain over the top reactions when it is not needed. The guy in the video could have handled his responses better and more professionally.

Maybe (and I am assuming, here) a number of Linux kernel developers that behave like this may not have worked in a corporate environment, and have not learned that certain behaviours are not acceptable. Probably have not been a team lead in a project, either. They might be effing good programmers, tho!

That is an assumption, of course. I could say the same thing about Linus, as his responses could/should be handled better over the lifetime of the Linux kernel. Of course, the kernel is HIS BABY and I understand if he gets annoyed reviewing CRAP code.

> Would you labor under such uncertainty and creeping adoption for a year or two, raise the points ad nauseam, get no concrete answers and NOT, at some point, lose your patience ?

Yep, that's what was happening to the RfL devs.