The subject is considerably more complex and nuanced than expressed by these one or two (obviously frustrated) people. I won’t presume to capture all the issues, but this person on HN does a decent job of capturing some of them:
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.
That this discussion repeats itself can only be taken to be either:
Evil C programmers are stodgy and old, and can’t/won’t get with the program, boo!
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. Some questions:
Who tests to avoid this?
Who’s expected to fix it? The one changing the C code, who might not know Rust or a separate bindings team?
Is there a process ? A person to contact/raise the issue with? To get help or to have the work done?
What happens if the bindings cannot be fixed in time for the next Kernel release? Put differently, will Rust bindings changes hold back changes to the C code?
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.
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.
And then there is this angle, which also exists:
The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover.