I mean, they came with enthusiasm and a lot of hard work, brought a new language with many advantages (as said by the BDFL humself), dusted off the whole GPU stack, tried to formalize a bit the FS systems, then got shunned out by the greybeards because “muh youngsters and their religion”.
> or expresses some caution
Bellowing about religions while monopolizing a talk Q&A is not “expressing some caution”.
Stereotyping an entire viewpoint as you did in your previous comment is pretty much always wrong. I might be a bit more forgiving if it has included some context or details, but it doesn't. Your post is little more than an insult.
I will add that people having been choking each other over all sorts of technical stuff for as long as this "free software" thing has existed, because there are usually 20 ways to do anything and typically between 2 and 10 ways are reasonable. This is really nothing new and discussions surrounding Rust are really not that special.
> You're trying to convince everyone to switch over to the religion as promulgated by Rust, and the reality is that ain't gonna happen because we have 50+ filesystems in Linux. They will not all be instantaneously converted over to Rust. Before that happens, we will continue to refactor C code because we want to make the C code better. If it breaks the Rust bindings, at least for the foreseeable future, the Rust bindings are a second class citizen, and those filesystem that depend on the Rust bindings will break, and that is the Rust bindings problem, not the filesystem community at large problem, and that's going to be true for a long long time. And I think we just simply need to accept that, because the answer "you are not allowed to refactor the C code because it would break 5 critical filesystem that distros depend upon" is not a starter. So we'll see; I suspect the best thing to do is for you to continue maintaining your Rust bindings. Over time, there will be continued C code refactoring -- maybe we will start using kfree RCU. If that breaks Rust, we will find out whether this concepts of encoding huge amount of semantics into the type system is a good thing or a bad thing, and instead of trying to convince us to what is actually correct, let's see what happens in a year or two. And it will either work or it won't, and we will see, more likely, where does the pain get allocated. Because with most of these sort of engineering things it's almost always a pain allocation question.
> [...]
> You're not going to force all of us to learn Rust -- if I make a change, I will fix all of the C code, because that's my responsibility. Because I don't know Rust, I'm not going to fix the Rust bindings.
Some of his language is more emotionally charged than was productive, sure, but I think his underlying concern is reasonable: most kernel maintainers don't know Rust, and so when they make changes to C code, they won't be able to fix Rust clients of that C code. The Rust maintainers accept this, and agree to take responsibility for updating Rust code to match changes in C (which is contrary to the usual development workflow of the kernel, hence the concern over what happens if major distros start depending on Rust code).
Note also that Ts'o isn't objecting to including Rust in the kernel! His recommendation is to ship the Rust bindings and see "where the pain gets allocated" as the C code continues to evolve. (The idea being that either Rust's type system and borrow checker will make it easy to identify semantic breakages early, thus making Rust code lower-maintenance than C, or the Rust bindings will turn out to be fragile and high-maintenance, and that the best way to tell is by waiting to see).
I'm not a part of the Linux kernel community at all, and I certainly don't know all the context that led to Almeida leaving the project -- I imagine Ts'o's comments were a "straw that broke the camel's back" kind of thing. But the Linux kernel is a complex project and critical infrastructure, so surely concerns about organization and maintainability need to be hashed out before Rust can make it to production.
Also, Ts'o's comments struck me as some of the most reasonable out of that talk, at least from a technical perspective -- the next commenter after Ts'o objects to Rust in the kernel on the basis that its function call syntax reminds him of Java.
The issue here is that this wasn't decided in this moment: it was decided as soon as the Rust was approved to merge. You're right that it's a concern, which is why it was addressed back then, and so a few years later, bringing it up feels like an argument in bad faith rather than a genuine attempt to bring a concern to the table.
There's a lot that you can say about all of that, but calling it "bad faith" is not great, to put it mildly. I had seen the video before, but didn't realize the person speaking is Ted Ts'o (I'm sad case and don't recognize Linux developers by voice alone). Ted has spent about 30 years working on all of this stuff, including investing a great deal of his spare time on it. He isn't some sort of random internet troll or anonymous HN user. Dismissing his views as "bad faith" does not leave me impressed.
I know who Ted is as well. That's why I expect better behavior. Then again, I'm not involved in any way, so my opinions don't really matter.
People are people and people can often "do better" in many ways on account of being people. That doesn't mean they're acting in bad faith.
That's precisely it, and why we also usually call behavior like Ted's "passive aggressive", and why Steve is right to call it out as seemingly made in bad faith. The person to whom he should address his complaints is the decider, the BDFL, Linus Torvalds, not anyone else.
Snipping, delay tactics, bureaucratic maneuvering, and endless bike shedding can poison projects. If you think Rust in the kernel is a mistake (not -- you think, in good faith, this implementation detail or that is technically incorrect), you need to plainly express that view to the person who makes the decisions, instead of whining to and about the people doing good work, endorsed by project leadership.
It's fine to be on record that "this thing will never work". It's less fine to work non-constructively to kill something before it gets an opportunity to work.
A long-term contributor with a great deal of investment in the project phrased things in the moment in a way that perhaps wasn't too brilliant (he was clearly emotional/nervous/whatever, as can be heard from his voice), and now he's somehow a bad faith actor trying to poison the project? Again just completely bizarre.
You come out here with some pretty big accusations based on basically nothing other than "he strongly disagrees". Well, he, ehm, he is allowed to state those views. If you want to radically change how kernel dev works and expect people who have been working on this for 3 decodes to just nod and smile and voice disagreement only in the Approved Way™, then I think you will end up bitterly disappointed. That's not how it works anywhere.
You need to actually convince people. And yes, sometimes people will phrase things in a suboptimal way, but that doesn't mean they're acting in bad faith. Bizarre thing to claim with such aggression and force.
> Snipping, delay tactics, bureaucratic maneuvering, and endless bike shedding can poison projects.
So do your baseless accusations that border on character assassinations, or dismissing people's concerns as "bike shedding" that they're somehow no longer allowed to bring up.
If you want to hold people to high standards of kind, empathic, and careful communication, then start by employing those standards yourself. That is: it's okay to criticise Ted for how he handled things. It's not okay to guess at his motivations, dismiss his views outright, and things like that. One is (hopefully constructive) criticism. The other is a personal attack and exactly the sort of thing that toxifies these discussions.
I'm sorry you misunderstood me, because I said nothing about simply voicing one's discontent. I guess it needs to be stated explicitly:
Everyone, including Ted T'so, please feel free to voice your discontent.
My argument was only: When you do voice your discontent, please direct it to the right/responsible person (Linus) and not someone else. Or if it's easier for you: Don't shoot the messenger. Which I thought was clear when I said:
>> The person to whom he should address his complaints is the decider, the BDFL, Linus Torvalds, not anyone else.
> You come out here with some pretty big accusations based on basically nothing other than "he strongly disagrees".
I'm sorry, but recall you said:
>>> Just because it was discussed way back when doesn't mean everyone has to accept the resolution from that. People obviously think it wasn't addressed in a good way.
I only agreed with you about what I thought we both believed the problem to be: Ted, like some others, is frustrated by Rust being included in Linux, and is venting his frustration at the Rust for Linux maintainer, not Linus.
> So do your baseless accusations that border on character assassinations, or dismissing people's concerns as "bike shedding" that they're somehow no longer allowed to bring up.
To be very clear -- I didn't say these were examples of Ted's behavior, although I do think they are examples of bad behavior that have been directed at the Rust for Linux project. I thought was I clear in all my comments about what I believe the problem was re: Ted's behavior. I said Ted not taking his concerns directly to project leadership (Linus), and instead directing his ire at Wedson, was passive aggressive.
> It's not okay to guess at his motivations, dismiss his views outright, and things like that. One is (hopefully constructive) criticism.
Again -- I'm befuddled -- because I was responding to your own statement of the situation, quoted herein. If you read things differently now, 3 hours later, or you regret making that comment, because it was the first to guess at Ted's motivations, I'm fine to leave it here, but please refer to your own comment, before you start preaching to anyone else about good manners.
He is not "the right person". The disagreement was on how to best integrate Rust in the filesystem code. That's up to the filesystem people. The great success from Linux comes from Linus not doing that kind of micromanagement. This is not how kernel dev works or has ever worked.
If "assume good faith and don't dismiss arguments as bad faith" is guessing at people's motivations then I guess I am shrug.
Linus is absolutely the right person because the subject for discussion was the inclusion of Rust for Linux in the kernel.
Despite this being very clear, you're now trying to conflate the "Filesystems in Rust" discussion with what you were referring to the broader Rust for Linux question.
I mean -- you're pretty slippery, but I can certainly remind you again of what you wrote:
>>>>> Just because it was discussed way back when doesn't mean everyone has to accept the resolution from that. People obviously think it wasn't addressed in a good way.
Now, I'm sure you remember what was being discussed "way back when"? Yes, it was the argument re: inclusion of Rust for Linux in the kernel, not the "Filesystems in Rust" discussion.
> If "assume good faith and don't dismiss arguments as bad faith" is guessing at people's motivations then I guess I am shrug.
I completely agree this is ordinarily the right way to act, but there are limits to what we can accept in good faith. When someone acts as passive aggressively as Ted T'so has, or as slippery and dishonest as you have here, even if it's embarrassing to me to have to point such things out, I think it's right to say "Wow maybe someone needs to have a talk with Ted or arp242". Despite your (bad) behavior, I still want someone to be honest and direct with you.
I remember a HN comment that I really liked and can’t find now that went something like:
You know what stopped me from programming? It wasn’t that I didn’t have a good computer. It wasn’t that I started later than all the other kids. It wasn’t that I had to work. Nothing. Nothing stopped me from programming.
There’ll always be folks like that. And I hope I’ll be like that for some thing too!