110

One Of The Rust Linux Kernel Maintainers Steps Down - Cites "Nontechnical Nonsense" (www.phoronix.com)

submitted 2 months ago by shield_gengar@sh.itjust.works to c/rust@programming.dev

29 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] 7uWqKj@lemmy.world 13 points 2 months ago

What exactly is the "nontechnical nonsense" he’s complaining about?

[-] mumblerfish@lemmy.world 37 points 2 months ago

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.

[-] soulsource@discuss.tchncs.de 5 points 2 months ago

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.

[-] FizzyOrange@programming.dev 15 points 2 months ago

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!" 🙄

[-] Corbin@programming.dev 3 points 2 months ago

At some point, reading kernel code is easier than speculating. The answer is actually 3. there are multiple semantics for filesystems in the VFS layer of the kernel. For example, XFS is the most prominent user of the "async" semantics; all transactions in XFS are fundamentally asynchronous. By comparison, something like ext4 uses the "standard" semantics, where actions are synchronous. These correspond to filling out different parts of the VFS structs and registering different handlers for different actions; they might as well be two distinct APIs. It is generally suspected that all filesystem semantics are broken in different ways.

Also, "hobby" is the wrong word; the lieutenant doing the yelling is paid to work on Linux and Debian. There are financial aspects to the situation; it's not solely politics or machismo, although those are both on display.

[-] FizzyOrange@programming.dev 3 points 2 months ago

Well that just sounds insane. Isn't the whole point of an abstracted API that you can write code for it once and it works with all of the implementations?

[-] soulsource@discuss.tchncs.de 3 points 2 months ago

I would be very surprised if they wouldn't fix all 50 filesystems.

In all projects I have worked on (which does not include the Linux kernel) submitting a merge request with changes that don't compile is an absolute no-go. What happens there is, that the CI pipeline runs, fails, and instead of a code review the person submitting the MR gets a note that their CI run failed, and they should fix it before re-opening the MR.

[-] FizzyOrange@programming.dev 6 points 2 months ago

submitting a merge request with changes that don’t compile is an absolute no-go.

Right but unless the tests for all 50 filesystems are excellent (I'd be surprised; does Linux even have a CI system?) then the fact that you've broken some of them isn't going to cause a compile error. That's what the linked presentation was about! Rust encodes more semantic information into the type system so it can detect breakages at compile time. With C you're relying entirely on tests.