I wonder how much of it is unwillingness to explain rather than the inability to do so? The vibe I got was that the audience was not interested in changing their ways, after all they've been doing things their way for decades with great success. I have to also credit the presenters, they stayed on the topic and pretty calm despite the heckling.
If that presentation encapsulates the state of things, the Rust for Linux definitely have their work cut out for them. Borrow checker seems like a small matter compared to the political issues.
Exactly. And as far as I understood the talk, nobody even asked the audience to change their ways.
Now, as mentioned by the presenter himself, refactors that change the API semantics will break any consuming code, no matter if written in Rust or C.
So, one option is that the whole issue around breaking Rust bindings is just a strawman and the vocal part of the audience just wants Rust devs to gtfo.
In the other, more charitable setting I can conceive, we are looking at an API that isn't extensively documented in the first place (obviously, otherwhise the Rust for Linux team wouldn't have to ask for clarification) and a small group of kernel devs who are trying to fix everything by themselves rather than documenting changes in a way that so other people can fix their own API-consuming code.
In this setting, also fresh would-be contributors using C will have a hard time getting to grips with the codebase. Now, if I remember correctly, one of the purported reasons for Linux to open up to Rust was to attract fresh developers, but in the outlined scenario, there is a clear reason why people might bounce off, and it is unrelated to the language (at least if this case is representative for other parts of the kernel codebase).
None of the options look good to me. But perhaps I am just missing something.
If that presentation encapsulates the state of things, the Rust for Linux definitely have their work cut out for them. Borrow checker seems like a small matter compared to the political issues.