this post was submitted on 09 Sep 2024
608 points (98.7% liked)
Linux
5393 readers
200 users here now
A community for everything relating to the linux operating system
Also check out [email protected]
Original icon base courtesy of [email protected] and The GIMP
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Yea, so mainly one situation that isn't explained here. Is that the moment you introduce a different language besides C, you now need to talk between C and this other language. This is called language bindings.
The problem with this, is the moment something is changing in C, and this method or interface is used by some Rust code, the Rust binding to C or C to Rust binding is failing, cause all kinds of issues.
Long story short, is that by introducing this additional language you created this technical issue of language bindings. And people who just want to work with C code, now suddenly also need to think about Rust bindings, while they previously didn't need to think about that. As if the Linux kernel isn't complicated enough, introducing this language binding issue is cause more (unwanted) work for some people.
In the end the "C" people are blaming Rust if something fails. And the "Rust" people are trying to explain and help the "C" people to introduce those bindings. waaaahhhh
It's not about the bindings. It's, as always with kernel devs, about gatekeeping and unprofessional if not outwardly hostile behavior.
Maintaining bindings is a hard problem for sure, but no hard problems have ever been solved by the key stakeholders refusing to partake in honest discussions. Asahi Lina's breakdown of her rejected contributions to the fundamentally flawed
drm_sched, which do not involve a single byte of Rust, demonstrates an unwillingness to collaborate that goes much further than the sealioning about muh bindings.