Long time “old-school” kernel maintainers don’t know Rust and don’t want to learn Rust (completely fair and reasonable). But some of them don’t want to work with the Rust guys for lots’o’technical reasons.
It’s by far not an easy situation technically. Like this is a huge challenge.
But some of those old-school C guys are being vocal about their dislike of Rust in the kernel and gatekeeping the process. This came to a head at a recent conference (Linux Plumbers Conference?) and now one of the Rust maintainers has quit.
The big technical challenge is being confounded by professional opinions.
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.
The un along with other governments are requiring all software including open source to be validated by a 3rd party security audit, C is notorious for its memory leaks and so switching to Rust is almost legally mandated but C is the foundation of modern society and switching will literally require rewriting linux from the ground up since Rust didn’t exist when it was made needles to say developers are not happy having to essentially learn a new language and start from scratch only harder because they can’t change anything they just need to rewrite it in another language and get nothing in return but happy bureaucrats as happy as bureaucrats can be anyway.
Yea that whole Rust drama is a pain. Linus unfortunately brought this upon himself. I believe he is also the guy that can fix it be either: Let’s remove Rust from the kernel again or… Saying: Just deal with it, we also support Rust, but Rust isn’t mandatory.
He can focus on solving the technical problems. Like have a list of things that has to be done in order for people to be happy with it. Missing feature? Starting guide? Limit what features can be used? C to Rust converter?
He does not have to solve it alone, like he did with git. He just need to decide the direction.
Just in time for the Rust debate to kill its momentum development wise! (/s, likely)
I’m unfamiliar with the “Rust” situation, has something gotten crusty or something?
Long time “old-school” kernel maintainers don’t know Rust and don’t want to learn Rust (completely fair and reasonable). But some of them don’t want to work with the Rust guys for lots’o’technical reasons.
It’s by far not an easy situation technically. Like this is a huge challenge.
But some of those old-school C guys are being vocal about their dislike of Rust in the kernel and gatekeeping the process. This came to a head at a recent conference (Linux Plumbers Conference?) and now one of the Rust maintainers has quit.
The big technical challenge is being confounded by professional opinions.
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.The un along with other governments are requiring all software including open source to be validated by a 3rd party security audit, C is notorious for its memory leaks and so switching to Rust is almost legally mandated but C is the foundation of modern society and switching will literally require rewriting linux from the ground up since Rust didn’t exist when it was made needles to say developers are not happy having to essentially learn a new language and start from scratch only harder because they can’t change anything they just need to rewrite it in another language and get nothing in return but happy bureaucrats as happy as bureaucrats can be anyway.
Is that one sentence?
deleted by creator
Yea that whole Rust drama is a pain. Linus unfortunately brought this upon himself. I believe he is also the guy that can fix it be either: Let’s remove Rust from the kernel again or… Saying: Just deal with it, we also support Rust, but Rust isn’t mandatory.
And in the latter, he also need to think about Rust FFI bindings to C… But I digress now. I don’t want to discuss this here.
He can focus on solving the technical problems. Like have a list of things that has to be done in order for people to be happy with it. Missing feature? Starting guide? Limit what features can be used? C to Rust converter? He does not have to solve it alone, like he did with git. He just need to decide the direction.