Comment by simjnd | Hacker News Reader

Comment by simjnd | Hacker News Reader

Parent Full thread

> You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other maintainers and contributors.

What change exactly is being imposed? Rust has been accepted, so that parts of the kernel can be written in either Rust or C. Nobody is pushing for an entire kernel rewrite in Rust. Nobody is pushing out C maintainers.

> The Rust minority has, as of yet, failed to properly answer what happens when C APIs change in either signature or semantics, either of which can break the Rust bindings.

He answers in the very video: there is a process and it is communication. When a C API change which can break the Rust bindings, you email the maintainer responsible for the Rust bindings. It's as simple as that.

> If broken bindings indeed can hold back changes, then C changes are held back by Rust and indeed then the onus is on the committer to either forego improving/evolving the C API or pick up Rust and fix the bindings also. In that case, yes, the Rust bindings will either freeze the C API or force the individual contributor to learn Rust.

This is already happening with C development anyway, when an API change causes drivers maintained by different people to be updated, but nobody is saying "C changes are held back by C".

> That people repeat their concerns isn't an expression of stupidity any more than a result of the people driving Rust into the kernel have yet to properly communicate how they envision this process to work, I suppose.

But in this video, you see someone driving Rust into the kernel communicating how they envision this process to work, and a guy adopting a hostile tone claiming to be an engineer and calling another language a religion. This isn't concern, this is discrimination.

Theodore Ts'o, the person you are implying is not an engineer, started working on Linux in 1991. Just look at the MAINTAINERS file of the Linux kernel source tree. You'll find Theo maintaining several critical pieces, including leading the ext4 file system development, but really, take a look.

Just to underline this. You are calling the credibility of a man whose code has most assuredly had a hand in storing your files, whether on your laptops/workstations or servers you've deployed to. A person who has been contributing for nearly *32 years*.

How about we flip this around ? Here's a person who's been a large part of the success of the Linux kernel project for 32 years, and here's this presumptuous group coming in left field, telling him he's doing it all wrong and that it's time to get with the program or buzz off.

People like him, the old guard, the core contributors, the main drivers of maintenance, should absolutely be heard. Linux is what it is today because of them. It's too precious to entrust to a bunch of well-meaning, but somewhat preachy and largely unproven developers.

-----

So he comes off rude. But how come the people driving the Rust integration into the kernel are still ducking the hard discussion?

It is almost as if everything is proceeding under the banner of "just an experiment" until, hopefully, a switch can be flipped and it becomes required, and everyone either has to maintain those bindings or see their patches rejected. Even better, then people who never wanted to pick up Rust, has to, or twiddle their thumbs in the background until some kindly soul decides to provide the updates to the bindings.

Would you labor under such uncertainty and creeping adoption for a year or two, raise the points ad nauseam, get no concrete answers and NOT, at some point, lose your patience ?

> Would you labor under such uncertainty and creeping adoption for a year or two, raise the points ad nauseam, get no concrete answers and NOT, at some point, lose your patience ?

Yep, that's what was happening to the RfL devs.

Nope.

RfL was accepted as an experiment[0], with the understanding that it CAN be ejected again if the evaluation fails. Its mandate was as an opt-in functionality, primarily left for individual maintainers to decide on whether to use and leaf-nodes to use.

It is very likely that this was the very best the RfL project could hope for at that time. Had they pushed for first-class citizenship, other contributors would, sensing the impending impact on their work, likely have revolted and the proposal would have been rejected.

So here we are - this is what the RfL people of the time chose over rejection. No one is changing the game on the RfL devs - if you contribute, you are doing so knowing that this is the official state of affairs.

The problem arises because while individual device drivers and subsystem maintainers indeed can opt-in, bindings provided by RfL impact contributors and maintainers who otherwise wish to avoid using Rust. Namely, if you write Rust bindings for my subsystem and my changes break those bindings, what then ? Am I barred from maintaining my subsystem because you decided to wrap the API for a language I don't know ?

This is not the same as some C code consuming my subsystem breaks on a change, which I can easily fix. This means I now have to read those bindings, understand how they wrap my C API and how their expose API differs from mine (remember: idiomatic (fat) Rust bindings is the goal). I am now on the hook for bindings I had no say in providing or designing?

If you don't understand how this can seem problematic, or how this can seem like maintainers are being forced into learning Rust and maintaining bindings which may well be a non-trivial layer in between the C API and consuming Rust code, then I don't know how to make the problem easier to grasp.

Essentially, it's a very simple instance of "your freedom to swing your hands ends at the point where my face begins" - someone (the RfL binding writers) are swinging their fists about, hitting some maintainers on the nose, and being surprised that said maintainers are angry about that.

[0] - https://docs.kernel.org/rust/

There is a flaw in this reasoning.

Nobody ever said that a subsystem maintainer needs to fix Rust bindings.

As Ts'o correctly states, that's the problem of the bindings maintainers.

But there is no problem at all. All that the Rust people want is to be informed about breaking changes. Also they said they're happy to get instructions on the semantics of the C APIs. They seem to want to collaborate. The C people just want them out, as it seems looking at this episode.

> Theodore Ts'o, the person you are implying is not an engineer

Wow slow down there. Where did I imply he wasn't?

I did imply he absolutely didn't act as one. When you're having an engineering discussion and you are being dismissive of actual arguments and reduce that to """religion""" you are not acting as one, you are acting like a fool.

> Would you labor under such uncertainty and creeping adoption for a year or two, raise the points ad nauseam, get no concrete answers and NOT, at some point, lose your patience ?

Whatever the circumstances, I'm not giving a pass to anyone to act like a complete dickhead. Whether that be to Theodore and other toxic kernel devs or to the toxic Rust community. If you lose patience just take a break, don't shit on other people. How is that a controversial take?

> He answers in the very video: there is a process and it is communication. When a C API change which can break the Rust bindings, you email the maintainer responsible for the Rust bindings. It's as simple as that.

This is a gross oversimplification. So after emailing, do you wait for the rust bindings to be fixed? Do you just get your changes merged regardless? Does the rust bindings maintainer have a say in what form your change takes? Can this hold back a release?

> This is already happening with C development anyway,...

As I understand it, the rule is if you change something that breaks other code, it is your responsibility to fix it (e.g. callers and such). This is obviously straightforward if you know C.

> This is a gross oversimplification. So after emailing, do you wait for the rust bindings to be fixed? Do you just get your changes merged regardless? Does the rust bindings maintainer have a say in what form your change takes? Can this hold back a release?

I'm pretty sure they are just asking for emailing. Just a short shift to getting changes in advance some of the time rather than none of the time. It didn't sound like they were asking to cross the divide from Partition Tolerance + Availability to Partition Tolerance + Consistency, merely shifting things a step in that direction (I think the CAP theorem applies everywhere).

Reply on news.ycombinator.com