112
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 29 Aug 2024
112 points (100.0% liked)
Rust
5790 readers
6 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
There is a video linked in the article for context:
https://youtu.be/WiPp9YEBV0Q?t=1529
If I try to interpret the context, it could be C programmers just being negative to Rust because it is not C, that there is a conception of Rust programmers trying to enforce Rust on others, or that Rust programmers will break things.
Behind all the negative tone there is a valid concern though.
If you don't know Rust, and you want to change internal interfaces on the C side, then you have a problem. If you only change the C code, the Rust code will no longer build.
This now brings an interesting challenge to maintainers: How should they handle such merge requests? Should they accept breakage of the Rust code? If yes, who is then responsible for fixing it?
I personally would just decline such merge requests, but I can see how this might be perceived as a barrier - quite a big barrier if you add the learning cliff of Rust.
From what I understood, the Rust devs weren't asking to change the interface, only to properly document it, and asked the kernel devs to cooperate with them so that Rust for Linux doesn't break without warning.
The Rust devs were trying to say they were fine if the Rust code ends up breaking, and they would take care of it. But they got talked over but the kernel dev.