Retiring from the Rust for Linux Project – Wedson Almeida Filho
lore.kernel.org
lore.kernel.org
Then again, we have Linus Torvolds who, in the last 20 years, has been hell-bent against including C++ in the kernel despite backlash.. yet.. he has accepted Rust a year or so ago. He obviously sees Rust in a completely different manner compared to C++ -- even though you could write crap code in Rust as well.
I get it -- the amount of harcore C programmers are likely shrinking. This means, over time, the linux kernel will eventually have less maintainers. It seems, to me, that Linus accepts reality that he is getting older (54) and wont be the maintainer forever. The younger generation are going to be the back-bone of keeping the project alive and if they are NOT focusing their efforts on C.. then what are they focusing on?
Rust, as good as it is, does have hype riding behind it. We also have other "Nu" languages which are eventually getting their stable releases in the coming months/years. Again, is Rust the right choice?
I understand the backlash especially veterans who have put in their efforts on the kernel and have no wish to learn Rust. I am sure there are plenty of Rust people throwing their world views opinions yet barely wrote anything decent in C, if at all.
Seems like everyone has an opinion even if their views on the opposite end is lacking.
As I say I try to sit on the fence. I have not focused my efforts on Rust but I don't actively object to it. I am just skeptical it has been added too soon to the project... but that is my opinion.
It's been adopted for core components in Firefox, and Chromium/Android are likewise moving towards adopting Rust. In general, Rust has seen broad industry adoption from the likes of FAANG, M$, etc.
As far as I know, while alternatives like Zig may have their merits, they are simply nowhere close to Rust in terms of maturity and adoption. Not only would it take a decade for them to play catch-up, there's huge uncertainty around whether they will ever reach that point. So even if you assume Rust is approximately average on whatever technical axes, pragmatic concerns suggest it's the only real option.
Of course, one can always argue Linux has no need to adopt any new language. I don't think there is any serious concern that Linux will end up with no C programmers left to write kernel code.
That is still pretty young... and just because something has reached 1.0 (lets say ready for production use) does not mean there wont be any major changes following it.
As I mentioned, I am not a Rust programmer, but I would not be surprised there has been a lot of changes since 1.0 -- and, potentially, if you had a kernel with lots of Rust code.. trying to do upgrades is likely going to be a lot more work when compared to a language like C.
When you compare Rust to something like Odin - this is a language that attempts to be a proper improvement over C without the typical gotchas or quirks that C has kept for many years. It does not add new features for the sake of it... it is generally "complete" despite not reaching version 1.0 (though it is used in production software)
https://x.com/jakubtomsu_/status/1808091029188567497
> I don't think there is any serious concern that Linux will end up with no C programmers left to write kernel code
That isn't what I was saying. I am just being realistic that in order for Linux to thrive for the next 30 years, we have to accept that the younger generation are not likely focusing on the C language. There will be many, of course -- but could be significantly less than the numbers today. With this, I think this is the main reason, with Linus in his mid-50s now, why Rust has been accepted.
In my opinion, if Linus was still in his early 30s today, he might have rejected Rust the same way as he has C++.
Should there be some duty to approach reality in these comments?
Odin and Zig are interesting, but they are niche compared to Rust, right now. I say this knowing Rust is pretty niche itself! But Rust is on a different planet right now compared to where Odin and Zig are, etc.
> In my opinion, if Linus was still in his early 30s today, he might have rejected Rust the same way as he has C++.
I'm not sure what this says about Linus in his 30s, or the current retrogressive mood of certain C programmers. Whatever it is -- it is a (cosmic!) appeal to authority instead of a well reasoned analysis of why we should listen to this speculative Linus in his 30s, instead of Linus today.
What is wrong comparing Odin to Rust... or Zig to Rust.. or Zig to Odin? These languages exists and should not be ignored simply for being labeled as `niche`
The previous commenter referred Rust as being stable because it was version 1.0 nearly 10 years ago.. and I responded why this does not mean as much as people think. From 1.0 to (now) 1.80.1 -- how much change has Rust gone through? I would take a guess and say A LOT! I am sure Rust will get more changes in the next 10 years!
This is why I think adding Rust to the kernel is 10 years premature. How much changes will need to be done to the Rust code in the next 10 years... I am guessing a lot. Comparing that with C, it is now going through the process of moving from C89 to C11. Once moved to C11 is unlikely to move for quite some time.
Just because I bring up Odin and make (valid) points why it is a better C.. does not imply I think it should be added to the Kernel. It is a young language (like Zig) and I think they both have an interesting future ahead of them. I am just as interested seeing their journey in the next 10 years.. not just Rust.
> I'm not sure what this says about Linus in his 30s
I am just stating that it is hard to know REALLY what Linus thinks about Rust. I use Age as an example because he is likely making decisions, whether he agrees or not, for the future of the kernel beyond himself. He wont be maintainer forever. Thats all I say/write on this.
Such conservatism is fine(?), but I think it really should serve some purpose. You think Rust code will change, such that... it will not be understandable? You don't actually say. Why should we be concerned?
> I am just stating that it is hard to know REALLY what Linus thinks about Rust.
Perhaps that's why it sounds so weird, to my ear, to fantasize about how he really feels beyond the concrete technical reasons he's offered.
Its not about whether it is understandable or not -- it is NEW FEATURES!
I guess I still don't understand. Your concern is new features will do what exactly to old Rust code?
1. A toolchain is stable if new toolchains can still work with older code written for a previous version of the toolchain.
2. A toolchain is stable if there is a slow rate of change in the toolchain.
It would seem your parent is either in camp #2 or closer to #2 than #1.
3. A toolchain is stable if it has LTS releases and bugfixes are backported to them, regardless of how many changes each non-LTS release brings.
But I'm not sure if people think about stability like that often. I wish they did.
Of course, it wasn't sensible, but it felt like my burden to say something when the reasoning was "But MORE features! Can't you see MORE is MORE?!" Perhaps because it reminded me of Drew Devault's mind-numbing "Rust is not a good C replacement". My more detailed thoughts on which are here: https://news.ycombinator.com/item?id=41409049
Rust has seen slight interest, but saying that companies like Microsoft are 'moving towards adopting Rust' is just flat out wrong (you realise MS make their own language stack, right? and that it's far more used than Rust?). There's probably more ActionScript 3 in production at MS than Rust.
On the nine year point, your assumption appears to be that Zig is trying to learn from Rust and is behind, but I'm not sure what you're basing this on. Zig isn't trying to do what Rust does, and has no reason to try to relive Rust's growing pains - instead, Zig is trying sand away the rougher edges of C. Zig is not chasing nine years of Rust, it's building on fifty years of C.
Imho, the momentum isn't for moving to Rust, the momentum is for trying to bring memory safety to systems programming (as distinct from most other programming, where GC'd languages are already dominant). Personally, I quite like Rust, but these are early days, and it is not yet clear that Rust will be the language that wins this fight. The history of computing is littered with examples of the slightly less elegant but more practical tool triumphing over the pure but inflexible one.
There has been a number of languages in 20 years that have been given hype - some more than others... yet slowly disappear into the corner.
Ruby and Clojure are 2 examples in the last 13 years. Today, I rarely hear about them (though I am sure they could still be popular in certain places)
To me, Rust is different to these examples.. and more comparable to the sort of hype and popularity Java got back in the 90s. Point is Rust is not going away like these other examples... and the fact Microsoft has included Rust in their kernel (like Linux as and, I believe, BSD) tells you a lot.
Microsoft are likely to still push their stack (.NET, etc) for frontend development. However, for their low-level+high performance codebase, likely behind their azure infrastructure, I would not be surprised if they start going with Rust.
Personally, I would love to see languages like Odin and Zig be more popular but I think Rust is going to dominate many areas in programming. Does not mean Zig or Odin wont be successful, it just wont get that fanbase Rust has, imo. The question you have to ask (like Java) is -- is it really the best choice for its features... or by its push/popularity.
Rust definitely has more going for it than some of the earlier hype cycles. That being said, and speaking from my own experience with Rust, there are some design choices that I suspect may pose a barrier for its widespread adoption. Rewriting small discrete components while maintaining C interop is a very fine use case for Rust - building and maintaining a large, complex, and stateful system wholly in Rust is quite another. I'd be very, very surprised if Microsoft switched en masse to Rust for their bare metal stack, at least with Rust in its current shape.
Clojure is a great parallel to bring up here, and should serve as a cautionary tale for Rust: Java was unpopular, Clojure showed that a better way was possible - but was itself just a bit too alien and hard to work with for many Java devs - so the more-familiar Kotlin swept in and carried the day. I have a sneaking suspicion that this might happen again, with C/C++ in the role of Java, Rust in the role of Clojure, and _ in the role of Kotlin. I don't quite know what the _ will be yet, but I suspect it will be a lot more accommodating to grizzled C wizards than Rust is. (I'm keeping an eye on Zig.)
Yes, I am keeping an eye not just on Rust -- but Zig and Odin. I personally like Odin, but I don't think it will shake off its reputation as a gaming language (like Jai) -- but I hope they change that marketing strategy.
Microsoft is making Rust a first-class system at Microsoft and investing 10 million dollars towards it apparently:
https://twiiit.com/dwizzzleMSFT/status/1720134540822520268 (nitter)
https://x.com/dwizzzleMSFT/status/1720134540822520268 (twitter)
If you watch the video Wedson linked to in his email, you will see a fragment of the typical experience of a Linux Rust kernel maintainer. Rust in the kernel does not and has never meant C developers will have to learn Rust, but despite that fact a lot of C kernel developers who have been doing an insane amount of gatekeeping, deliberately treating Rust as a second-class citizen out of spite.
Asahi Lina who has written the kernel part of the Apple M-series GPU driver in Rust has had a LOT to say about what interacting with kernel developers have been like: https://vt.social/@lina/113045455229442533
I am not ignoring or denying there isn't individuals throwing their toys out of the pram when follow-up discussions should remain respectful and mature.
On one end, I get it. Linux kernel is a BIG project. I assume it is still the biggest Free/Open Source project today. Many developers involved in this project genuinely care about it. These big projects will NOT go down well if a release contains bugs. By having another language in the equation is likely to cause tension especially code breakages. Now, these guys need to learn Rust! When a language like Rust is given a lot of push today I can understand their anger when it can feel like it is pushed into the kernel too soon too quickly.
I am not defending these guys - I am just saying I get it. However, on the other end, I do not want to see a project contain over the top reactions when it is not needed. The guy in the video could have handled his responses better and more professionally.
Maybe (and I am assuming, here) a number of Linux kernel developers that behave like this may not have worked in a corporate environment, and have not learned that certain behaviours are not acceptable. Probably have not been a team lead in a project, either. They might be effing good programmers, tho!
That is an assumption, of course. I could say the same thing about Linus, as his responses could/should be handled better over the lifetime of the Linux kernel. Of course, the kernel is HIS BABY and I understand if he gets annoyed reviewing CRAP code.
I think the key point of contention here is that the Rust maintainers are insisting this isn't the case. For them, they retain oversight on the Rust bindings, not the C components they reference. What they expect is that when a breaking change happens, they are able to reach out to maintainers of the C component and get documentation, issue threads, etc that might help them resolve those issues.
For Ts'o, maybe the concern is that producing the docs would be onerous, or that in reality they may have to provide more than the minimum expected level of support. I don't personally think the former is a reasonable complaint. I think the latter has grounds for discussion and compromise. And if he is passionate about the kernel as a project, he should introspect about how likely it is that the community will retain or expand its strength as he throws loud public tantrums voluntary contributions to it.
That seems incorrect. If I am writing software which interacts with a component, then I need to be able to read it to understand what it’s doing. So if a software system includes Rust, then developers of the system will need to at least be able to read it.
That’s not saying anything bad about Rust, at all: it’s just a property of developing in a shared codebase.
Full disclosure: I dislike C but can read it, and I cannot read Rust. Rust sounds like it really is an improvement over C in many ways, but it does seem to suffer from some social problems. As a Lisp user, I can sympathise.
I don't see how this case would be different.
This is why I want to work on multi-kernel NixOS — I want to make this threat as credible as possible.
If ever new kennel requires one to switch to an entirely different user land arbitrarily, they're just imposing stupid switching costs that hamper competition. If you can easily get your experimental kernel and rig it up with NixOS, we could have a real renaissance for systems programming.
Is this something people have been working on, or is this "just" something on your personal todo list?
Maybe only tangentially related, but I have been pretty excited about https://spectrum-os.org/
https://spectrum-os.org/ is very cool too!
> Spectrum will, for now, be a Linux-based system, with packages from Nixpkgs but not derived from NixOS.
This is because NixOS is not actually so flexible/extensible. I hope multi-kernel NixOS helps with that in general
git mailing lists have such a greybeard IRC vibe to them. i will, from now on, use "only accepts patches per mail" as a proxy for "not worth suggesting new ideas to" for all projects. it's a stupid proxy. correlation and causation and all that. but it's a very useful one for your sanity.
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.
That this discussion repeats itself can only be taken to be either:
1) Evil C programmers are stodgy and old, and can't/won't get with the program, boo!
2) 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. Some questions:
* Who tests to avoid this?
* Who's expected to fix it? The one changing the C code, who might not know Rust or a separate bindings team?
* Is there a process ? A person to contact/raise the issue with? To get help or to have the work done?
* What happens if the bindings cannot be fixed in time for the next Kernel release? Put differently, will Rust bindings changes hold back changes to the C code?
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.
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.
The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover.
If I am contributing to the Linux kernel already, I presumably have a decent grasp of C, the central abstractions in the code I am changing, the email-based patch workflow and so on. So when my code breaks adjacent code, I should have a good chance of fixing those issues also, and most often, this won't become the main body of work.
If jamming in Rust bindings means the great mass of existing contributors are forced to learn Rust, whether they wish or not, to either maintain bindings or to drop out altogether, then raising the pitchforks is not an unreasonable response.
It's unreasonable for educated grown men to react like 12yo children and resist change cause "we don't like eating our vegetables even though they are good for our health". If you actually care about the Linux kernel you will find a way forward even if that means communicating with people or even changing habits.
At the end of the day I don't think that the people that are contributing to the Linux Kernel do it out of good will but rather more about than prestige and building a resume. Or else we wouldn't have this resistance to progress.
What you don't understand about what you call "pro-Rust crowd" is that there is a reason to push for memory safety and encoding the invariants in the type-system. It's the closer you can get to a mathematically proven system.
If you don't want one of your most core systems to be as robust as possible against security vulnerabilities, even if that means going out your way either learning something unfamiliar or god forbit communicating, like you have more emotional quality than a potato, with other people then you are a horrible person.
"I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust."
I do wonder if peoples mindset, especially kernels developers, would have a change of tune if Linus himself goes out of his way to learn Rust.
I doubt he is and, likely, has no interest in learning it, either. He is not in the position where he is forced to for the most part. However, from what I remember, he does review a lot of code and makes the final decision what gets merged into the main branch. I wonder how much use he will be when... perhaps in the next 10 years... the lower-level code he review becomes more and more Rust.
I guess by then -- which I covered a little in my comment on here -- is likely to be retiring by then.
I just think Linus, the guy that would says there is "Nothing better than C!" - could change the culture in the kernel world if he becomes decent at Rust programming. In reality, I think he would get annoyed fighting the borrow checker. Maybe I would be proven wrong.
No, it just means that when their changes are ready, if they break the Rust bindings then then just need to fire off an email to the Rust people to update the binding. This is no different than having to get an approval before merging a branch. They don't have to code differently at all. It just slows down the merge. That's it.
i understood your argument being a technical one, and not a social one. i have no opinion on this topic from the technical side.
Some of the minutae concerns were definitely valid, if a little disruptive in the conversation which could have been a bit more considerate but are ok and not too unusual for these summits.
Ted was IMO extremely rude though. The tropes he came in with, and the tone, were disrespectful, trolly and rude, and they didn't offer any value whatsoever. Here's a breakdown:
Opens with "we're almost out of time here" - aka, I'm gunna make a point, but we're not going to discuss it. Opening statement continued "I suspect part of the problem here is that you're trying to convince everyone to switch over to the religion as promulgated by rust". Kent certainly did spend probably too long talking _prior to examples_ about language features and how they avoid bugs. If they'd have said "here's an API we wrote and here's why we did it this way", that might have come across a little less preachy, but at no point did they actually get overly preachy, and this statement was born much more out of some other set of conversations or fears, and wasn't an appropriate reflection of what they'd been presenting or discussing _at all_. It was a direct challenge against their actions, but actions they hadn't taken, it's almost a personal attack. Ted closes that opener with "and the reality is that ain't gunna happen", which steps this opener which is already bordering on a personal attack into absolutism, dismissal and aggression.
Opening statement still continued "because we have 50 plus filesystems and they will not all be instantly converted over to rust" - no one said or suggested anything of the sort, this is an absurd point and again is extremely disrespectful, because it implies they think otherwise, which is an absurd implication at this level - absurdity to the point of rude and insulting.
Continuing still, Ted barely takes a breath, a strong indicator of excessive emotional content. "before that happens, we will continue to refactor the C code because we wanna 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 filesystems 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 gunna be true for a long long time". So yes, there's a central point in here which is a somewhat clear statement that the C devs won't fix rust, and rust will break in between. That's fine, everyone essentially agrees, and the thing is this is responding to, well, nothing that was presented, no one presenting said or implied otherwise. The trailing "for a long long time" though is heavily coded, and it combines with the earlier coded implication, the combination of which is: anyone who writes a filesystem in rust will be broken for a long long time. This is again extremely aggressive. If the statement was "until rust becomes a first class citizen" it's extremely reasonable, but that's not what was said, not at all, and given the totality of the tone you can confidently say this was intentional. This was a statement to onlookers "don't do this if you're serious", aka, don't do this. This statement is also closed with, much like the start of the opening remark "and we simply need to accept that", aka, this is as i have stated it and there shall be no more discussion.
Cont. "the answer you're not allowed to refactor to the C code because it would break 5 critical filesystems that distros depend upon is like not a starter", well this isn't at all what he meant to say, he meant to say, and everyone took this as because it would break the rust bindings. Again this refers to some content that was not said in the presentation or the discussion. No one said the C couldn't be refactored. If we were to take the statement as stated, well, if there are 5 critical filesystems that distros depend on, regardless of what language they're implemented in, you don't get to just break them, and yeah, that's not a starter, this statement is useless content, everyone present knows Linux and Linus position on breaking userspace. Essentially this is pointless authority posturing, as it referred to none of the content under discussion.
Part two, not that he stopped other than to breathe and set for the next statement, in fact someone started to respond and he spoke over them, continuing: "okay, we'll see, I suspect the best thing to do is you to continue maintaining your rust bindings over time there will be continued C code refactorings right, maybe we will start using kfree rcu, if that breaks rust, we will find out whether or not this concept of encoding huge amounts of semantics into the type system is a good thing, or a bad thing, and instead of trying to convince us what is actually correct, lets see what happens in a year or two and it will either work, or it wont and we will see, or more likely where does the pain get allocated because with most of these sorts of engineering things its almost always a pain allocation question" so again here more aggressive downtalk, again a time reference saying this is still going to be second class in a year or two, lots of emphasis on bad out outcome alternatives as they're stated clearly implying that this is all a bad path. There's so much misunderstanding here as well, there's not a lot of semantics they encoded into the type system, the method in question had split between a refcounted fully initialized type and an uninitialized type, this isn't crazy, and it is composable. Take the example of switching to kfree rcu, well the uninitialized type would be unaffected, and if rcu was integrated with the existing refcount type, well that wouldn't change either, so this code would be untouched, but if it took over the refcounting sure, the refcount type changes, but none of the implementation code. that's a pretty good outcome - in the C, well for this example you've gotta go look in the content of every caller of the equivalent C function, as noted and agreed through the discussion, as the semantics are encoded at each call site individually, and not reused or composed. A final note on the whole pain side of things, summing this all up it's essentially: here's a bunch of choices that maximize your pain, and if your path is the most painful "we'll see" aka you're toast. Again this is really unnecessarily threatening and rude, it's not a collaborative discussion, it's all downtalk and aggression, and the core points, well everyone knows the core points, so they didn't need to be said at all.
Now the presenters respond, and they're just getting through saying "and while rust is a second class citizen i'm fine if you guys say i don't care about this you guys should look at it", and Ted jumps in, almost talking over the end of that sentence, clearly not hearing it, because he says "here's the thing" (now with a raised voice), "you're not gunna 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 gunna fix the rust bindings" then very sarcastically "sorry". He wasn't listening, he doesn't care to listen, he's angry, he wants these people gone, and well, per this article he got some of his way, but frankly this is disgusting, especially when you also consider Teds social weight.
Repeatedly the actual ask that they had was "can you tell us where the semantics are", and implied "and when they change", and mostly what they got was gall and no actual response to those requests (from key actors). A few others did engage in good faith, and were asking what the semantics are of the Rust code and did offer some semantics inputs. I'm not sure who it was but the FS contributor who spoke a lot to the presenters on the way through, he, while interrupting most of the presentation for at least 15 of the 30 minutes, right at the end had essentially talked himself around to the function signature being pretty good. It'd have been nice if he did a bit more of that in his head, but I know the summits do tend to allow for a lot of this interrupty direct engagement, and so it's mostly within keeping, he took a lot of time but ultimately did engage somewhat productively.
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.
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.
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).
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 ?
Yep, that's what was happening to the RfL devs.
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.
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.
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?
Let the Rust folks go off and do their own kernel project(s). If they can come up with something feasibly better, it will be adopted and they can displace the current C-based Linux kernel. Based on what I've seen of Rust and the crowd that has taken to it, this does not seem a likely outcome. (Worse yet, maintainers are dropping Rust packages for practical reasons.) Still, they should try so that they can see for themselves while leaving the current developers to their existing affairs.
Like parents separating two fighting children, both sides of this need to be pulled away and kept separated. The Rust crowd can go off and have their own project(s) and the Linux kernel can continue being only C-based. And never the twain shall meet. If the Rust crowd manages to build something better, it will replace the alternative. If not, they need to accept the reasons why without pleading to social media masses. We've seen PipeWire come along and replace PulseAudio. We've seen X11 keep a stronghold over Wayland. To the Rust crowd, focus your energy on building something somewhere else that you feel is better. To the Linux kernel developer crowd, it's time to move on from this experiment for everyone's peace of mind.
The companies actually paying for the kernel development want Rust. That's a matter of fact.
Just see who's sponsoring the Linux Foundation, and check what they said elsewhere about their long term commitment to Rust.
The main sponsors would likely just fork Linux should Rust be removed again. Than Linux would be left with "community contributions" and the trademarks, but all the big money would go to the fork.
Of course nothing like that will happen. Because Linus knows very well where the money is coming from.
This is news to me. Are there any actual grants or contracts that stipulate this? Can you provide any links to that effect?
> Just see who's sponsoring the Linux Foundation, and check what they said elsewhere about their long term commitment to Rust.
Is it the same people at these corporations? Are you assuming companies with five or six figures of employees have a unified stance on this? Or anything? If there was such a commitment to Rust, why not pull funding and cut a check to Redox? Or shift funds gradually over time? This is a head-scratching statement.
> The main sponsors would likely just fork Linux should Rust be removed again.
This is an asinine take. Three decades and millions of lines of code will not be simply forked overnight. These are the kinds of veiled threats that need to stop, especially when attached to such delusional levels of toxic wishful thinking.
Arguing in bad faith is destructive to the overall conversation.
You have an existent product line running on Linux. It looks like a no brainer to just get rust into Linux so you do not have to rewrite all your userspace code to work on Redox. You can keep your own drivers as well. You can gradually migrate piece by piece.
It looks simpler to fork the existing code base than support a brand new unproven OS where you do not even know if it will perform the same as your current one. The amount of investment looks smaller with the fork but maybe I miss something.
Okay, I've researched this quite a bit and it is totally false. Companies paying for kernel development are on older kernel versions and want certain features/fixes backported to their kernels. As of today, those backports are only supported in one language, C.
Look at RHEL 9. That shipped with kernel 5.14. For companies that are getting newer hardware or want capabilities that aren't available in 5.14, what do you think they would be paying for?
anyway, the point of the resignation is not wanting to deal with all this, not necessarily taking a side, so I’m not even disagreeing with you. But obviously, it is a disagreeable atmosphere. I don’t find that debatable, even if that’s due to people feeling paranoid about a (nonexistent?) rust religious takeover.
I think we can all admit Rust definitely has its ideologues and cult acolytes.
In other words, they simply requested adequate documentation and the response was "I'M NOT LEARNING RUST AND YOU CAN'T MAKE ME", effectively. That is nontechnical nonsense
So maintainer would have to either wait for Rust team to update their API or learn Rust.
Seems like an unnecessary dependency.
Warning: lots of stereotypes follow.
Rust believes APIs should be [close to] impossible to use incorrectly. So we get rich type system, contracts, and other kinds documentation. All corner cases are either impossible because of the type or explicitly written down in the contract. If UB happens because user wrote incorrect code, that's a library's bug because it did not defend against it.
C believes the programmer. Documentation typically mentions happy path and some popular errors only. Lots of assumptions are implicit, like thread-safety, reentrance, (lack of) NULLs, lifetimes of inputs/outputs. It's up to the user of the library to figure out restrictions if their usecase is not in the documentation. Common sense and knowledge of C traditions helps. If UB happens because the user did something a bit out of the usual, it's on the user.
That brings us to different mindsets of library developers.
In Rust you typically write code while proving that it's correct in all theoretically possible cases, otherwise the code does not even compile. If it becomes too hard, you refactor API, possibly making the implementation harder. But your API is kind of nice in the kind.
In C you take whatever piece of code you found to be useful, extract it in a function or two and use in the project. If you happen to need that exact code somewhere else, you use it. There is no need to prove that the code always works or that it's a sound abstraction. If it works, it works. If it stops working in some case because of a bad API design, then you decide whether it's worth refactoring or not. That makes the initial implementation simpler, but it lacks contracts by design.
So I attribute it to cultural differences between "C programmers" and "Rust programmers". For Rust programmers, "full function contract" is a must, so documenting it seems easy. For C programmers, "full function contract" is not required for writing working code in 95% of cases, so documenting it is extra chore with no benefit.
I do half-agree though... I think somewhere inside Rust there is a hidden simpler language, with only a tiny subset of its features, but which still has lifetimes. I'd love to see that language.
That's probably the reason.
> I think somewhere inside Rust there is a hidden simpler language, with only a tiny subset of its features, but which still has lifetimes
That's exactly the language I would like to upgrade to from C.
In theory, possibly. In practice, there are a number of technical and social obstacles standing in the way of such a feature.
The first big technical problem is that standard C is currently not very well-suited for borrow checker-style automated lifetime/ownership analysis. Much of the information the borrow checker needs just not present in the C type system, and while some information may be inferable from function bodies separate compilation and the dynamic nature of ownership make things really hard, if not impossible in the general case.
Of course, one could require the addition of lifetime/ownership annotations, but that is a pretty substantial backwards compatibility break - there's a lot of existing C code out there, and they'd need to be annotated to be usable in a Rust-style borrow checker. That's an automatic deal-breaker for a lot of people.
So what happens if you just try to work with what you have? Then you basically end up where existing static analysis tools are - they can catch some lifetime/ownership errors, but that's on a best-effort basis an can potentially be very resource-intensive.
> why do we have to write "let" to define a variable?
The most common explanation I've seen is that it makes parsing and/or type inference easier. In addition, let is also more than just a variable declaration - it can be used more generally for binding/destructuring/pattern matching (e.g., if let Some(Point(x, y)) = p { do_something(x, y) }.
> why did they completely change the syntax if the goal is to be a C alternative!?
Because those changes are (arguably) improvements?
Yeah unfortunately.
I have no dog in this race, but basic logic says if the linux kernel contains rust code, then a linux kernel dev will either need to learn rust or avoid doing things that require changes to those parts of the code.
I don’t know how you can wave this away as “technical nonsense”.
Now, if rust is only in a few corners of linux, then there isn’t much distinction between a linux C dev and a full linux dev, and it’s no big deal. But the goal appears to be to use it more extensively than that.
To me, the entire approach to this is backwards. Rather than trying to force a preconceived solution, turn it around and say to linux devs “Look, memory safety is an issue in linux. What can be done about it?” Let them determine the solution. That’s when you can make the case for rust. (Though you probably won’t be successful if you keep blowing off the concerns of linux devs.)
I don't blame this guy. It's the people who let the Barbarians in, because politics.
Sometimes gates need to be kept.