Hacker News Reader

Comment by diggan | Hacker News Reader

> And then he can't help himself. After being so reasonable, he throws shade on Rust. Shade that is just unfortunately, just false?

Many discussions online (and offline) suffer from a huge-group of people who just can't stop themselves from making their knee-jerk reactions public, and then not thinking about it more.

I remember the "Filesystem in Rust" video (https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s) where there are people who misunderstand what the "plan" is, and argue against being forced to use Rust in the Kernel, while the speaker is literally standing in front of them and saying "no one will be forced to use Rust in the Kernel".

You can literally shove facts in someone's face, and they won't admit to being wrong or misunderstand, and instead continue to argue against some points whose premise isn't even true.

I personally don't know how to deal with this either, and tend to just leave/stop responding when it becomes clear people aren't looking to collaborate/learn together, but instead just wanna prove their point somehow and that's the most important part for them.

View on HN

If you watch that YouTube link, you'll see the same guy Ted Tso'o accusing the speaker of wanting to convert people to the "religion promulgated by Rust". I think he apologised for this flagrant comment, but this email shows he hasn't changed his behaviour in the slightest.

His email seems very reasonable to me (the thin-blue-line comment is a bit weird though). To me the problem are that some Rust people seem to expect that the Linux maintainers (that put in a tremendous amount of work) just have to go out of their way to help them achieve their goals - even if the maintainers are not themselves convinced about it and later have to carry the burden.

How many times will this need to be said: the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. The only "burden" the C maintainers have to carry is to CC a couple of extra people on commits when APIs change.

I don't think it is this simple.

This is not how the kernel works. You cannot rely on someone's "commitment" or "promise". Kernel maintainers was to have very good control over the kernel and they want strong separation of concern. As long as this is not delivered, it will be very hard to accept the Rust changes.

At some level this is just concern trolling. There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just expressed. You are asking for something that is impossible.

What could they possibly "deliver" beyond a strong commitment to fix the code in a timely manner themselves?

> There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just exprssed.

They could do exactly what Ted Ts'o suggested in his email [1] that Marcan cited: They could integrate more into the existing kernel-development community, contribute to Linux in general, not just in relation to their pet projects, and over time earn trust that, when they make promises with long time horizons, they can actually keep them. Because, if they can't keep those promises, whoever lets their code into the kernel ends up having to keep their promises for them.

[1] https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed...

Many of them have, in fact, done all of those things, and have done them over a time horizon measured in years. Many of the R4L developers are paid by their employers specifically to work on R4L and can therefore be considered reasonably reliable and not drive-by contributors.

Many existing maintainers are not "general contributors"

It is unreasonable (and a recipe for long-term project failure) to expect every new contributor to spend years doing work they don't want to do (and are not paid to do) before trusting them to work on the things they do want (and are paid) to do.

Christoph refused to take onboard a new maintainer. The fight from last August was about subsystem devs refusing to document the precise semantics of their C APIs. These are signs of fief-building that would be equally dangerous to the long-term health of the project if Rust was not involved whatsoever.

I disagree. If you want to provide technical leadership by massively changing the organization and tooling of a huge project that has been around a long time, it should be absolutely mandatory to spend years building trust and doing work that you don't want to do.

That's just how programming on teams and trust and teamwork actually works in the real world. Especially on a deadly serious not-hobby project like the kernel.

Sometimes you are gonna have to do work that doesn't excite you. That's life doing professional programming.

Everything Ted Tso recommended is just common sense teamwork 101 stuff and it's just generally good advice for programmers in their careers. The inability of rust people to follow it will only hurt them and doom their desire to be accepted by larger more important projects in the long run. Programming on a team is a social affair and pretending you don't have to play by the rules because you have such great technical leadership is arrogant.

Wedson had been working in the kernel for 4.5 years!

> It is unreasonable (and a recipe for long-term project failure) to expect every new contributor to spend years doing work they don't want to do (and are not paid to do) before trusting them to work on the things they do want (and are paid) to do.

It is absolutely reasonable if the work they want to do is to refactor the entire project.

it's like saying to people that they cannot add for example npu subsystem to kernel because they should first work for 10 years in other subsystems like filesystems on with they know little about.

sound absurd? just replace subsystems in above with C/Rust and the rest is the same.

Folks that maintain rust are responsible for rust code, if they won't deliver what is needed, their rust subsystem will fail, not C codebase, so it's in their own interests to keep things smooth.

my feeling is that some people think that C is the elite language and rust is just something kids like to play with nowadays, they do not want learn why some folks like that language or what it even is about.

I think the same discussion is when Linux people hate systemd, they usually have single argument that it's agains Unix spirit and have no other arguments without understanding why other thinks may like that init system.

The issue with systemd was that many people felt that it was pushed onto them while previously such things would just exist and got adopted slowly if people liked it and then actively adopted it. This model worked fine, e.g. there were many different window managers, editors, etc. and people just used what they liked. For init systems, distributions suddenly decided that only systemd is supported and left people who did not want it out in the cold. It is similar with Rust. It is not an offer, but something imposed onto people who have no interest in it (here: kernel maintainers).

If users of other init systems don't want to make the substantial investment in maintaining support for those other init systems, then their complaints weren't worth much.

> it's like saying to people that they cannot add for example npu subsystem to kernel because they should first work for 10 years in other subsystems like filesystems on with they know little about. sound absurd? just replace subsystems in above with C/Rust and the rest is the same.

No it's not. What you're missing is that if the Rust folks are unable, for whatever reasons, to keep their promises, it falls on the up-tree maintainers to maintain their code. Which, being Rust code, implies that the existing maintainers will have to know Rust. Which they don't. Which makes it very expensive for them to keep those broken promises.

To look at it another way, the existing maintainers probably have a little formula like this in their heads:

Expected(up-tree burden for accepting subsystem X) = Probability(X's advocates can't keep their long-term promises) * Expected(cost of maintaining X for existing up-tree maintainers).

For any subsystem X that's based on Rust, the second term on the right hand side of that equation will be unusually large because the existing up-tree maintainers aren't Rust programmers. Therefore, for any fixed level of burden that up-tree maintainers are willing to accept to take on a new subsystem, they must keep the first term correspondingly small and therefore will require stronger evidence that the subsystem's advocates can keep their promises if that subsystem is based on Rust.

In short, if you're advocating for a Rust subsystem to be included in Linux, you should expect a higher than usual evidence bar to be applied to your promises to soak up any toil generated by the inclusion of your subsystem. It’s completely sensible.

> What you're missing is that if the Rust folks are unable, for whatever reasons, to keep their promises, it falls on the up-tree maintainers to maintain their code.

But that's the thing, the deal was that existing maintainers do not need to maintain that code.

Their role is to just forward issues/breaking changes to rust maintainer in case those were omitted in CC.

You are using the same argument that was explained multiple times already in this thread: no one is forcing anybody to learn rust.

> You are using the same argument that was explained multiple times already in this thread: no one is forcing anybody to learn rust.

I think this sort of statement is what is setting the maintainers against the R4L campaigners.

In casual conversation, campaigners say "No one is being forced to learn Rust". In the official statements (see upthread where I made my previous reply) it's made very clear that the maintainers will be forced to learn Rust.

The official policy trumps any casual statement made while proselytising.

Repeating the casual statement while having a different policy comes across as very dishonest on the part of the campaigners when delivered to the maintainers.

The point is that “the deal” assumes that the Rust folks will keep their promises for the long haul. Which kernel maintainers, who have witnessed similar promises fall flat, are not willing to trust at face value.

What if, in years to come, the R4L effort peters out? Who will keep their promises then? And what will it cost those people to keep those broken promises?

The existing kernel maintainers mostly believe that the answers to the questions are “we will get stuck with the burden” and “it will be very expensive since we are not Rust programmers.”

Isn't it the same as with support for old hardware? Alpha arch, intel itanium, floppy drives?

Those are all in similar situation, where there is noone to maintain it as none of maintsiners have access to such hardware to event test of that is working correctly.

From time to time we see that such thing is discovered that is not working at all for long time and noone noticed and is dropped from kernel.

The same would happen to rust if noone would like to maintain it.

Rust for Linux is provided as experimental thing and if it won't gain traction it will be dropped in the same way curl dropped it.

The reason the maintainers can drop support for hardware nobody uses is that dropping support won't harm end users. The same cannot be expected of Rust in the kernel. The Rust For Linux folks, like most sensible programmers, intend to have impact. They are aiming to create abstractions and drivers that will deliver the benefits of Rust to users widely, eliminating classes memory errors, data races, and logic bugs. Rust will not be limited to largely disposable parts of Linux. Once it reaches even a small degree of inclusion it will be hard to remove without affecting end users substantially.

It is not concern trolling. It is a harsh disagreement.

Some kernel developers really do feel that any Rust in the kernel will eventually mean that Rust gets accepted as a kernel language, and that they will eventually have to support it, and they the only way to prevent this is to stop any Rust development right now.

And yes, there's nothing that the R4L group can offer to be get around that belief. There isn't any compromise on this. Either Rust is tried, then spreads, then is accepted, or it's snuffed out right now.

A big mistake by R4L people is seeing anti-Rust arguments as "unfair" and "nontechnical." But it is a highly technical argument about the health of the project (though sometimes wrapped in abusive language). Rust is very scary, and calling out scared people as being unfair is not effective.

OP said "As long as this is not delivered"

There is nothing to deliver that would satisfy this argument. Pretending like the disagreement is about a failure of the R4L folks to do "enough" when in fact there is nothing they could do is toxic behavior.

If you go back digging in the LKML archives, Christoph's initial response to Rust was more of a "let's prove it can be useful first with some drivers"

https://lore.kernel.org/lkml/YOVNJuA0ojmeLvKa@infradead.org/

https://lore.kernel.org/lkml/YOW2auE24e888TBE@infradead.org/

That has now been done. People (particularly Marcan) spent thousands of hours writing complex and highly functional drivers in Rust and proved out the viability, and now the goalposts are being moved.

R4L people are allowed to get upset about people playing lucy-with-the-football like this wasting their f***ing time.

Yeah, that's an interesting point that even Christoph sounded open to it in the past. Thank you!

To start, not resigning when things don't go their way. That tendency is doing a lot to make the claim of rust people saying they will handle the burden of rust code unbelievable.

The standard procedure is to maintain a fork/patchset that does what you want and you maintain it for years proving that you will do the work you committed to.

Once it’s been around long enough, it has a much better chance of being merged to main.

That has already been the case with Asahi Linux - for years. It exists as a series of forked packages.

The thing is, you do still have to present a light at the end of the tunnel. If, after years of time investment and proven commitment, you're still being fed a bunch of non-technical BS excuses and roadblocks, people are going to start getting real upset.

However, it may only get merged in by being conceptually re-thought and reimplemented, like the Linux USB or KGI projects back in the day.

The general pushback for changes in Linux are against large impactful changes. They want your code to be small fixes they can fully understand, or drivers that can be excluded from the build system if they start to crash or aren't updated to a new API change.

You can't take a years-maintained external codebase and necessarily convert it to an incremental stream of small patches and optional features for upstream maintainers, unless you knew to impose that sort of restriction on yourself as a downstream maintainer.

As of today, the burden is uncertain and the Rust crowd has not been fixing things quickly enough since they are manual fixes:

https://lore.kernel.org/rust-for-linux/20250131135421.GO5556...

> Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not.

> Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders".

> It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build.

For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads?

> For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads?

Yes actually, I really wish someone would bring that sort of thing to the forefront, because that's a great spot to welcome new contributors.

As a non-interested observer; I think it will need to be said until the commitment becomes credible. I don't know how it would become credible, but it's clearly not considered credible by at least those of the kernel maintainers who are worried about the maintenance burden of accepting rust patches.

This is not what the "Rust kernel policy" [1] of Rust for Linux says.

[1]: https://rust-for-linux.com/rust-kernel-policy

> Who is responsible if a C change breaks a build with Rust enabled?

> The usual kernel policy applies. So, by default, changes should not be introduced if they are known to break the build, including Rust.

> Didn't you promise Rust wouldn't be extra work for maintainers?

> No, we did not. Since the very beginning, we acknowledged the costs and risks a second language introduces.

You conveniently left out

> However, exceptionally, for Rust, a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side. The breakage should nevertheless be fixed as soon as possible, ideally before the breakage reaches Linus.

Yes, "breakage should be fixed as soon as possible". Not "Rust for Linux team will fix the breakage as soon as possible".

The exception is allowing the subsystem to break Rust code temporarily. If you accept a patch in C that breaks Rust code, and the Rust for Linux team doesn't fix it quickly enough, you either need to fix the Rust code yourself, remove it, or re-write it in C. All of this would take time and energy from all the non-R4L kernel devs.

This is why people are reluctant to accept too much mixing of the C and Rust codebases, because even the Rust for Linux team isn't promising to fix breakages in Rust for Linux code.

Just to be clear, this is the situation. A rando submits a C patch that breaks Rust code, a maintainer accepts this patch and then demands that the R4L devs fix the breakage introduced by someone else and reviewed by themselves. The rando who broke the thing isn't around, and the person who reviewed the change takes no responsibility.

Have I gotten that right?

And then you're presenting this situation as "the Rust for Linux team isn't promising to fix breakages in Rust for Linux code". Somewhat disingenuous.

Why? You seem to describe one potential scenarios where Rust creates additional work.

To say Rust won't cause extra work for C developers, this is exactly what people are claiming. This is from the comment I originally replied to.

> The Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. The only "burden" the C maintainers have to carry is to CC a couple of extra people on commits when APIs change.

But this is not actually true it seems. Even the Rust for Linux policy doesn't say this. But because of the incorrect statement that keeps getting repeated, people are calling Kernel devs unreasonable for being reluctant to Rust patches.

You just proved the C devs point..

> A rando submits a C patch that breaks Rust code, a maintainer accepts this patch and then demands that the R4L devs fix the breakage introduced by someone else and reviewed by themselves. The rando who broke the thing isn't around, and the person who reviewed the change takes no responsibility.

Well, firstly, "randos" aren't getting their patches easily accepted anyway.

And secondly, what's the problem with this? You want one of the following options:

1. Everyone who wants to submit a patch also be proficient in Rust,

2. You want the reviewer to also be proficient in Rust

You don't think that's an unnecessary burden for the existing maintainers?

The burden should be on the people who want to introduce the second language.

They've said that, but nobody believes them, and can you blame them given we JUST saw another big rust maintainer resign?

I'd be suspicious these guys aren't in it for the long haul if they don't get their way and will leave the Rust they shoved in the kernel to bit rot if things don't go their way w.r.t enough rust adoption fast enough. "If you don't let us add even more rust, we will resign from the project and leave you to maintain the rust that's already there and that we added, and that you said you didn't want to add because you didn't trust us to not resign".

Rust 4 Linux people just proving the points of the maintainers scared of abandonment.

The rust 4 Linux people unfortunarely give the impression of caring more about rust than about the kernel, and it's clear that many are willing to make that perfectly clear by abandoning the larger project.

The whole thing needs to be scrapped and rethought with better and more committed leadership. This past 6 months to a year has been embarrassing and done nothing but confirm the fears of anti rust people.

These people were quitting after being harassed. So I do not think you are arguing in good faith.

That doesn't line with https://rust-for-linux.com/rust-kernel-policy#who-is-respons... (which may be a recent change?)

> the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side.

How have they "committed"? By saying they commit[1], I presume -- but what more? Anyone can say anything. I think what makes the "old guard" kernel maintainers nervous is the lack of a track record.

And yes, I know that's a kind of a lifting-yourself-by-your-bootstraps problem. And no, I don't know of any solution to that. But I do know that, like baron Münchhausen, you can't ride your high horse around the swamp before you've pulled your self out of it.

___

[1]: And, as others in this thread have shown, that's apparently just out of one side of their collective mouth: The official "Rust kernel policy" says otherwise.

> "the thin-blue-line comment is a bit weird though"

In US, "thin blue line" is a colloquialism for police officers who typically wear blue and "toe the line." You should not be downvoted/shadowbanned/abused for your post, IMHO.

> Ted Tso'o accusing the speaker of wanting to convert people to the "religion promulgated by Rust"

Given the online temper tantrum thrown by marcan, Ted Tso'o's comment seems totally reasonable, regardless of one's opinion of Rust in the Linux kernel.

Ted gave that rant 6 months ago, and it was in fact unreasonable if you look at the details of what they were discussing.

You're trying to use Marcan's ragequit to ex-post-facto justify Ted T'so when it's literally the other way around.

Quite frankly, if I had the realization that despite assurances to the contrary, that my contributions to a project had been sabotaged for months or even years up to that point, I would have also had a hard time keeping a smile on my face.

This is ultimately what this drama comes down to. Not if Rust should or shouldn't be in the kernel, but with kernel maintainers' broken promises and being coy with intentions until there is no other option than to be honest, with the reveal that whatever time and effort a contributor had put in was a waste from the start.

It seems like the folks who didn't want Rust in the kernel will be getting their way in the end, but I had better never hear another complaint about the kernel not being able to attract new talent.

I can't believe you're the first person I find in this conversation who raises this issue. This is the exact reason why Marcan flipped his lid. Linus publicly championed a very technically complex initiative and then left all those contributors to the wolves when things didn't progress without a hiccup. Especially damning when you consider that at every step, the fief lords in Linux have seemingly done everything in their power to set up the r4l people for failure and Linus hasn't so much as squeaked at them. He personally cut the knot and asserted that Rust is Linux's future, but he constantly allows those below him to relitigate the issue with new contributors (who can't fight back because even though they're contributing by the supposed rules, they don't have enough social buy-in).

> He personally cut the knot and asserted that Rust is Linux's future,

When did he say that?

In any event, that could be true (Rust is Linux's future) while the statement "R4L is not in Linux's future" is also true.

IOW, in principle, I may agree with you on something. That doesn't mean I agree with your specific implementation.

> my contributions to a project had been sabotaged

I really wish people would stop throwing around the word "sabotaged". No one "sabotaged" anything. The opposition has been public from the beginning.

If I'm opposed to something, and someone asks my opinion about it in a private conversation, it is not "sabotage" to express my opinion. So far I haven't seen any evidence that those opposed to a mixed-language code base organized behind the scenes to hamper progress in anyway. Instead, their opposition has been public and in most cases instant.

Are people not allowed to be opposed to things anymore?

> tharne 4 minutes ago | parent | context | flag | on: Resigning as Asahi Linux project lead

> > Ted Tso'o accusing the speaker of wanting to convert people to the "religion promulgated by Rust"

> That seems totally reasonable. Putting aside the technical merits of the Rust language for the moment, the Rust community suffers from many of the same issues currently hobbling the Democratic Party in the United States. Namely, it often acts like a fundamentalist religion where anyone who dares dissent or question something is immediately accused of one or another moral failings. People are sick of this nonsense and are willing to say something about it.

It's really interesting that every time I open a thread like this, countless people come out swinging with this claim that Rust is totally this religion and cult, while the rest of the thread will be full of C evangelism and vague rhetorics about how nothing like this ever works, while actively contributing to making sure it won't this time either.

99% of insufferable Rust vs. C interactions I've come across it was the C fella being the asshole. So sorry, but no, not very convincing or "totally reasonable" at all.

> 99% of insufferable Rust vs. C interactions I've come across it was the C fella being the asshole. So sorry, but no, not very convincing or "totally reasonable" at all.

This has also been my observation as a C++ developer who finds themselves in a fair few C/C++-aligned spaces. There are exceptions, but in most of those spaces the amount of Rust Derangement Syndrome I've witnessed is honestly kind of tiresome at this point.

> Rust Derangement Syndrome

Thank you for proving me so right so readily.

...they were agreeing with you, not being insufferable.

> ...they were agreeing with you, not being insufferable.

Those two things are not mutually exclusive :-)

We have used that video as an exercise in how not to achieve change. Assuming everyone is acting in good faith, the presenter missed the opportunity to build consensus before the talk, Tsu unwilling to budge a bit, but most of all the moderator unable to prevent the situation from exploding. This could have been handled much better by each of them.

In contrast to the parent: yes, the presenter says „you don’t have to use rust, we are not forcing you“ but he fails to address the concern that a change they introduce would error downstream and someone else had to clean up afterwards.

> We have used that video as an exercise in how not to achieve change

I'm not disagreeing with anything you said, just curious who the "we" you're referring to here, are you a kernel developer or something similar?

> Assuming everyone is acting in good faith

Why would we assume that Ted repeatedly using strawman fallacies, bleating appeals to emotion and acting like a victim...all the while shouting people down...evidence of "acting in good faith"?

When you shout over someone like that you're nothing but a bully.

> he fails to address the concern that a change they introduce would error downstream and someone else had to clean up afterwards.

Because that "concern" was a strawman. It demonstrated that Ted either did not understand what the presenters were asking for, or simply didn't like others asking him to do something, because he's very important and nobody tells him what to do.

As has been exhaustively explained by others in previous HN threads and elsewhere: the Rust developers were asking to be informed of changes so that Rust developers could update their code to accommodate the change.

Ted loses his shit and starts shouting nonsense about others forcing people to learn Rust, and so on.

> but most of all the moderator unable to prevent the situation from exploding

When someone is being abusive to others, the issue is never "the people on the receiving end are not handling it as best they can."

Further: did it occur to you that Ted's infamous short temper, and his "status" as a senior kernel developer, might be why the moderator was hesitating to respond?

Imagine how Ted would have reacted if he was told to speak respectfully, lower his voice, and stop talking over others. Imagine how the army of nerds who think Ted's behavior was acceptable or understandable.

I don't understand how abusive bullies like Ted are allowed the privilege of being a senior kernel developer. This feels, in the end, like the fault of Linus, for allowing abusive maintainers to maintain their grip.

Linus was the original abusive bully maintainer, that's how. He's improved his personal use of language, but the culture that he initiated continues unabated. Linux's existing success as a project is used as evidence that it doesn't need any changes to the kernel maintainers' culture.

Up until recently (assuming you believe he's genuinely reformed), Torvalds was also one of those abusive bullies, remember.

I'm not a rust or c developer.

> As has been exhaustively explained by others in previous HN threads and elsewhere: the Rust developers were asking to be informed of changes so that Rust developers could update their code to accommodate the change.

I don't understand why you don't see this as "a really big deal". The C developers make a breaking change. They fix all the C code, then they write an email to the Rust devs explaining the changes.

Then the process of making the change stops, and the C devs have to wait for a Rust dev to read the email, review the C changes, fix and test the resulting rust, and check in the update. (including any review process there is on the rust side.)

Is it hours, days, or weeks? Are there 2 people that know and can fix the code, or are there 100's. Do the C devs have visibility into the Rust org to know its being well run and risks are mitigated?

This is adding a hard dependency on a third party organization.

I would never dream of introducing this kind of dependency in my company or code.

This is kernel development we're talking about. It progresses carefully, not a the breakneck pace of a continuous integration SaaS platform that is single-minded about pushing features out as quickly as possible.

A better analogy would be like an API inside of a monolithic app that has multiple consumers on different teams. One team consumes the API and wants to be notified of breaking changes. The other team says "Nah, too much work" and wants to be able to break the API without worrying about consequences.

If having multiple consumers of an API or interface is a goal, you make communication a priority.

> Why would we assume that Ted […] acting in good faith?

Because he has done more for Linux than you ever will. Therefore, he gets all the benefit of the doubt, and you are assumed wrong

>In contrast to the parent: yes, the presenter says „you don’t have to use rust, we are not forcing you“ but he fails to address the concern that a change they introduce would error downstream and someone else had to clean up afterwards.

He did not fail to address that concern. And then Ted shouted him down for 2 minutes such that he couldn't get 2 syllables in to respond.

> "no one will be forced to use Rust in the Kernel"

Is this true, though? One reason for this altercation seems to be the basic circumstance that in Linux kernel development, if there is a dependency between two pieces of code A and B, the responsibility to keep B consistent with changes to A lies, in order, with anyone proposing patches to A, the subsystem maintainer for A, and finally the subsystem maintainer for B. If B is Rust code, such as a binding, then that's potentially up to 3 people who don't want to use Rust being forced to use Rust.

They're not "forced to use Rust". They are maybe forced to work with Rust developers of whichever subsystem needs to be updated, but that would always have been the case with the C developers of whichever subsystem needs to be updated too.

I don't think that is a correct interpretation. As I understand it, Linux does not have a notion of someone being obliged to help facilitate a patch, especially if it's not the narrow case of a maintainer and a patch to the subsystem they are in charge of. What do you do if you are a C developer modifying system A, your change has implications for system B which includes Rust code, and none of the Rust developers involved with B care to volunteer time to draft the necessary changes to Rust code for you?

The same situation of course also arises between C-only subsystems, but then the natural solution is that you have to go and understand system B well enough yourself that you can make the necessary changes to it and submit them as part of your patch. In that situation you are "forced to use C", but that's a free square because you are always forced to use C to contribute to Linux code.

>They're not "forced to use Rust". They are maybe forced to work with Rust developers of whichever subsystem needs to be updated

So if the maintainer of subsystem X can be forced to work with the rust developers of their own subsystem, then that rust developer just got promoted to co-maintainer with veto power. Effectively that's what they'd be, right? I can see why maintainers might not like that. Especially if they don't think the rust dev is enough of a subject matter expert on the subsystem.

If a subsystem C developer makes a change and introduces a bug in another driver or subsystem (also written in C) as a result, then you would expect them to be able to help at least insofar as explaining what they changed.

That isn't "effective co-maintainership".

I've been in a spot kinda like this. I've maintained C++ with python interfaces. In my case I wrote both. I know how interlocked the changes were. If I touched code that was exposed to the python, I updated the python interface and the consumers of that python interface.

It was nothing like making changes that cut across into another developer's C++ code (hell, I would even update their python interfaces/consumers too). That was temporary coordination. The python part was much more frequent and required much more detailed understanding of the internal APIs, not just the surface.

Having someone else responsible for the python part would have come at a huge cost to velocity as the vast majority of my changes would be blocked on their portion. It's ridiculous to imply it's equivalent to coordinating changes with another subsystem.

It's absolutely not true, it's one of the lies being told by Rust 4 Linux people. The end goal is absolutely to replace every last line of C code with Rust, and that's what they will openly tell you if you speak to them behind closed doors. That's why there is always an implicit threat directed at the C maintainers about job loss or "being on the right side of history". The Rust 4 Linux people are absolutely attempting a hostile takeover and nobody should believe a word that comes out of their mouths in public mailing lists when they are contradicting it so consistently behind closed doors.

> You can literally shove facts in someone's face, and they won't admit to being wrong or misunderstand, and instead continue to argue against some points whose premise isn't even true.

This is like probably 80% of people and fundamentally why the world is a hellscape instead of a utopia.

Maybe try not shoving things into people's faces and you'll find them to be much friendlier.

Nah, that's not the case. Not for that 80%. And even if they are friendlier, being willfully ignorant with a smile and a nod doesn't make it better.

The speaker doesn't understand the audience question and doesn't respond to it.

The audience member points out that they shouldn't encode the semantics into the Rust type system because that would mean that refactoring the C code breaks Rust, which is not an acceptable situation. The speaker responds to this by saying essentially "tell me what the semantics are and I'll encode them in the Rust type system." That's maximally missing the point.

The proposal would cause large classes of changes to C to break the build, which would dramatically slow down kernel development, even if a small handful of Rust volunteers agree to eventually come in and fix the build.

> You can literally shove facts in someone's face, and they won't admit to being wrong or misunderstand, and instead continue to argue against some points whose premise isn't even true.

I have to say that I used to be excited about Rust, but the Rust community seems very toxic to me. I see a lot of anger, aggression, vindictiveness, public drama, etc. On HN you not infrequently see down voting to indicate disagreement. These clashes with the Linux maintainers look really bad for Rust to me. So bad that I'm pretty convinced Rust as a language is over if they're no longer banging on the technical merits and are instead banging on the table.

I'm sure there are great things about the community. But I would encourage the community to have higher standards of behavior if they want to be taken seriously. The Linux team seem like they're trying to look beyond the childishness because they are optimistic about the technical merits, but they must be so tired of the drama.

> I have to say that I used to be excited about Rust, but the Rust community seems very toxic to me. I see a lot of anger, aggression, vindictiveness, public drama, etc.

I had the same impression.

Why all this drama is 90% of the time around Rust people?

The kernel is not exactly known for being drama-free, and this drama didn't start with "Rust people", it started with Christoph.

Was Hellwig first, or Andre Hedrick, or maybe Hans Reiser?

Because many of them are still relatively young. There is nothing wrong with youth, but it can contribute to over-zealousness.

Also, for many of them, Rust is the first systems language they've ever touched. And that fact alone excites them. Because now they can "dream big" too.

But they have bought into the whole C/C++ are by default insecure and therefore garbage. In their mind, no mortal could ever write so much as a single safe function in those languages. So their points of view are always going to be based on that premise.

What they fail to recognize is that an operating system kernel, by virtue of the tasks it has to perform- things like mapping and unmapping memory, reading/writing hardware registers, interacting with peripherals, initiating dma transfers, context switching, etc.- have effects on the underlying hardware and the runtime environment; effects that neither the type system nor the temporal memory safety of Rust can model, because it happens at a level lower than the language itself. Rust's safety guarantees are helpful, but they are not infallible at that level. The kernel literally changes the machine out from under you.

They further fail to appreciate the significant impedance mismatch between C and Rust. When one language has concepts that are in fact constraints that another language simply does not have, there is going to be friction around the edges. Friction means more work. For everyone. From planning to coding to testing to rollout.

So you have well-intentioned, excited, but still self-righteous developers operating from what they perceive to be a position of superiority, who silently look down upon the C developers, and behave in a manner that (to outsiders at least) demonstrates that they really do believe they're better, even if they don't come right out and say it.

Just read the comments in any thread involving Rust. It is inconceivable to them that anybody would be so stupid or naive as to question the utility of the Rust language. To them, the language is unassailable.

The petty drama and social media brigading on top of it, along with the propensity to quit when the going gets tough, it's pretty easy to see why some people feel the way they do about the whole thing.

A programming language is not a religion. It is not a way of life. It is a tool. It's not like it's a text editor or something.

> But they have bought into the whole C/C++ are by default insecure and therefore garbage. In their mind, no mortal could ever write so much as a single safe function in those languages.

No one thinks this except some strawman that you've devised. No point in reading anything else in this comment when this is so blatantly absurd and detached from reality.

I'm sorry sir/mam, but that is simply not true.

All you have to do is read comments from members of the Rust community online, in every public forum where Rust is discussed in any way.

Understand, I am not trying to villainize an entire community of software developers; but for you to say something that's blatantly false is to just stick your head in the sand.

You should try and read the words people write. Opinions are not formed in a vacuum.

Edit: to be clear- I have no problems with Rust the language beyond some ergonomic concerns. I am not a Rust hater, nor am I a zealot. I do advocate for C# a lot for application code though. But I do not deride others' language preferences. You should not dismiss my observations because I used hyperbole. Obviously not every Rust dev thinks you can't write a secure C/C++ function; don't pick out the one hyperbolic statement to discredit my entire post. Bad form.

> A programming language is not a religion. It is not a way of life. It is a tool. It's not like it's a text editor or something.

I really hope that last sentence was a joke.

It was :)

Because that’s all your brain are capable of recalling, the ones with Rust-tagging.

With just a google search away you can dismiss your claim of 90% but you don’t want to do it because you only believe what you want to believe.

> The audience member points out that they shouldn't encode the semantics into the Rust type system because that would mean that refactoring the C code breaks Rust, which is not an acceptable situation. The speaker responds to this by saying essentially "tell me what the semantics are and I'll encode them in the Rust type system." That's maximally missing the point.

You have to encode your API semantics somewhere.

Either you encode them at the type system and find out when it compiles, or you encode it at runtime, and find out when it crashes (or worse, fails silently).

I disagree, they didn't straight out pointed this, because this is nonsense. Semantic changes can break anything, even if it's some intermediary API.

There are more breakage in rust due to the type-system-related semantics, but ideally a C dev would also want their system to break if the semantics aren't right. So this is a criticism on C..?

So following this argument, they don't want Rust because C falls short? Nonsense.

edit: The speaker did mention that they didn't want to force limited use on the base APIs, but that for a great deal of their usage, they could have determined fixed semantics, and make intermediary APIs for it. So this was not about limiting the basic APIs.

Here are the software requirements (inferred from the commenter):

- (1) the C code will be refactored periodically

- (2) when refactored internally it can break C code, but the change author should fix any breaking in C

- (3) Rust must not break when (1) happens

It's the Rust devs' job to meet those requirements if they want to contribute. It looks in the video like they don't understand this, which is pretty basic.

> You can literally shove facts in someone's face, and they won't admit to being wrong or misunderstand, and instead continue to argue against some points whose premise isn't even true.

I think that's part of the gag.

"These people are members of a community who care about where they live... So what I hear is people caring very loudly at me." -- Leslie Knope

https://www.youtube.com/watch?v=areUGfOHkMA

>"These people are members of a community who care about where they live... So what I hear is people caring very loudly at me." -- Leslie Knope

that's a very healthy and - I feel - correct attitude towards this kind of criticism. I love when wisdom comes from stupid places.

Its quite a well-known wisdom. I think someone in one of Nintendo or Sony's studios has said it too, in the form of: a complaint is worth twice a compliment.

Satisfied customers will tell you they think your stuff is great, but dissatisfied customers will be able to hone in on exactly where the problem is.

You can even extend this to personal life: if someone tells you your shabby car doesn't fit with the nice suits you wear, you can either take it as a personal attack and get irritated, or take it as feedback and wash your car, spruce up the upholstery and replace the missing wheel cap. In effect they helped you take note of something.

One does not "hone in" on anything. To hone a thing is to make it sharper or more acute by removing parts of it with an abrasive. The word you are looking for is "home", as in a homing missile, etc.

Yes, this is a criticism. Hopefully it's twice as effective as being nice. 8)

You knew what they meant, which is clear if you’re able to correct the use of language accurately. This isn’t a criticism per se, but an acknowledgment that language evolves and part of the way it does that is acceptance that “incorrect” usage, once common enough, is seldom reversed.

I went down a slight rabbit hole for this: apparently both are correct, although "hone in" doesn't seem to have a ground source and has gotten institutionalized in our lexicon over time.

By the way, I don't mind the nit at all! English is not my first language and I slip up occasionally, so refreshers are welcome :-)

Multiple dictionaries recognize the usage of "hone in" to mean "sharpening" your focus on something rather than "home in" which is to move towards something.

Dictionaries also (incorrectly) recognize "literally" to mean "figuratively". They aren't exactly a compelling source these days.

Show me one.

When "literally" is used in a figurative way, it's an intensifier. It means "very much". It never means "figuratively".

You may not hone in on anything, but people who are better at English do.

This would be doubly ironic if you're a native English speaker. Are you?

"All happy customers are alike; each unhappy customer is unhappy in its own way" - Tolstoy.

this isn't true, of course, but it sounds good

It's almost true, though, in a way: The only difference is, Tolstoy wrote "families", not "customers".

> dissatisfied customers will be able to hone in on exactly where the problem is

This sounds like a truism, when it isn't. The client may know something is wrong, but good luck at them identifying it. Some times, the client will convince themselves that something is wrong when it isn't. There were people complaining about lag in WoW, they responded by cutting the latency number in half... except that it wasn't cut in half, it was just measured as time to server rather than roundtrip. The complains died out immediately and they were hailed as "very savvy developers that listen to their customers".

who asked him to fix Rust bindings or even look at the Rust code? Seems like an emotional nut.

> You can literally shove facts in someone's face, and they won't admit to being wrong or misunderstand, and instead continue to argue against some points whose premise isn't even true.

It's called a strawman fallacy, and like all fallacies, it's used because the user is either intellectually lazy and can't be bothered to come up with a proper argument, or there isn't a proper argument and the person they're using it against is right.

If an honest alien says "we don't want to convert humans to our religion" that means you can have whatever religion you want. If a dishonest alien says it, it might mean "we don't want to convert humans because we are going to kill all humans", it's selectively true - they aren't going to convert us - and leaves us to imagine that we can have our own religion. But it's not the whole truth and we actually won't be able to[1].

An honest "no one will be forced to use Rust in the Kernel" would be exactly what it says. A paltering reading could be "we want to make Rust the only language used in the Kernel but you won't be forced to use it because you can quit". i.e. if you are "literally shoving facts in someone's face" and they don't change then they might think you are not telling the whole truth, or are simply lying about your goals.

[1] https://en.wikipedia.org/wiki/Paltering

And yet, you are bringing made-up analogy that suits you to the discussion.

Reply on news.ycombinator.com