> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't *have* to deal with Rust.
I don't have a citation but I remember reading last year complaints from C developers that they were being harassed by Rust maintainers to document their code better and stop making so many changes because it added a lot of difficulty to maintaining their Rust bindings and they didn't like the work of having to figure out how to safely use the APIs by having to read and understand the C code. There are various technical and historical details for why the C part operates like this.
So while it appears that Christoph is being unreasonable I have this little voice in the back of my head that reminds me of working with people and being told that I wouldn't have to change my process etc. And then, slowly, more and more soft demands are placed on you and your time, if you don't do it you're called not a team player, holding back progress, etc. And you end up in fact having to do more work to accommodate these soft demands.
Maybe this is just the reality of working in a team, but it doesn't change the fact that the claim is disingenuous, you will be expected to do more work, your work will be materially changed by having to work with these other people doing something you have no interest in, that none of this would be happening if you didn't have to accommodate this thing you don't care about that you were promised wouldn't affect you.
But this is all speculation. If Linus does what he says then it's not a problem. I would hold him to that and bring it up if people came to me with soft demands that I change my process. I would also file a code of conduct complaint if the person making demands decided to get people to dogpile me on social media, or put my name on a secret blacklist that they quietly give to new contributors to pre-spoil my working relationship with them.
The most important thing, or maybe the only important thing though, is that it felt before like Linus was fence-sitting and now he's actually saying how it's going to be, which is great and the right thing for BDFL.
@ignaloidas I am not going to say that there's no badly designed interfaces in there but the issue seems to be that everything in the kernel is in C where you have to manage a lot of stuff yourself because of decades of design decisions you can't change; and written without strongly opinionated abstraction because they can't assume how it will be used in other parts of the kernel. Here is a post by an Asahi kernel Rust dev talking about it:
@sun@shitposter.world I don't have a citation but I remember reading last year complaints from C developers that they were being harassed by Rust maintainers to document their code better and stop making so many changes because it added a lot of difficulty to maintaining their Rust bindings and they didn't like the work of having to figure out how to safely use the APIs by having to read and understand the C code. There are various technical and historical details for why the C part operates like this.Tbh that's just bad maintainership. Rust people try to write their interfaces in a way that you can't misuse them, and when trying to do that, they find code that's hard to impossible to not misuse, and the maintainers just don't want to fix their shit.
@ignaloidas I think that the problems can be categorized into:
1. design decisions largely based around having to manually manage resources across primitive building-block APIs, these APIs complexity are various mixes of "not ideal" and "necessary" 2. objectively bad APIs
@ignaloidas I think the reason that greg and linus speak in aggression and platitudes about this when forced to talk about it at all is because they all know the truth, which is that an extremely large, extremely old, and extremely decentralized open source C project doesn't have the code discipline to be interfaced with Rust without confronting historic bad decisions that should be rewritten but this would entail huge cost and risk. This directly and obviously conflicts with claims that Rust, which needs consistency and quality to make a safe shim, won't change anything, and forces out in the open issues with the perceived "quality" of the kernel.
@ignaloidas Yeah, I think the complaints of the Rust devs seem to be true whenever I look at it. Sometimes I get hung up on a tangential issue to a topic. In this case, Rust may be good for the kernel long-term but I am really bugged by people saying "it won't affect you" when I can tell it will.
@sun@ignaloidas what annoys me from this person is that they said that they found a lot of bugs or wrong stuff in the kernel C code and... did nothing beyond saying they could easily fix them "in rust".
@mischievoustomato@ignaloidas@zero it's less like "I found a bug" and it's more like "you designed this completely wrong and it is making everything worse for everyone else"
@mischievoustomato@ignaloidas@sun@zero don't worry, the bugs only happen if someone were to use their code wrong, like in a binding without an improved interface