What exactly is the “nontechnical nonsense” he’s complaining about?
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.
That seems based on the same misconception as the whole “fighting the compiler” view on Rust, namely that other languages are better because they let you get away with not thinking through the problems in your code up front. I am not surprised that this view is common in the C world which is pretty far on the end of the spectrum that believes that they are a “sufficiently disciplined programmer” (as opposed to the end of the spectrum that advocates for static checks to avoid human mistakes).
The problem you mention is fundamentally no different from e.g. changing some C internals in the subsystem you know well and that leads to breakage in the code in some other C subsystem you don’t know at all. The only real difference is that in C that code will break silently more likely than not, without some compiler telling you about it. The fact that the bit you know well/don’t know well is the language instead of some domain knowledge about the code is really not that special in practical terms.
Ask the Rust maintainers to fix it presumably? The antagonist in the video above claimed there are 50 filesystems in Linux. Do they really fix all 50 filesystems themselves when they change the semantics of the filesystem API? I would be very surprised. I suspect what actually happens currently is either
- They actually don’t change the semantics very often at all. It should surely be stable by now?
- They change the semantics and silently break a load of niche filesystems.
I mean, the best answer is “just learn Rust”. If you are incapable of learning Rust you shouldn’t be writing filesystems in C, because that is way harder. And if you don’t want to learn Rust because you can’t be bothered to keep up with the state of the art then you should probably find a different hobby.
These “ooo they’re trying to force us to learn Rust” people are like my mum complaining you have to do everything online these days “they’re going to take away our cheque books!” 🙄
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.
