It sounds more like it's mostly the standard kind of debate that happens over any significant API change in the kernel: you always get a variety of opinions on what the right way to do things. The additional complication is this by necessity is a parallel API and in a language which not everyone in the kernel knows, so there's some additional discussion about who's responsible for keeping thing in sync.
But I'd rather have 50 lines of nuclear fissile code that needs to be correct than say the whole software.
The danger of Rust it that you twist yourself into a bretzel in order to avoid unsafe, while you should have in fact made a exceptionally well tested and designed unsafe block that is surrounded by code that the compiler checks for you.
I am still convinced that the naming choice for unsafe has some effects that were not intended. Mentally whenever you see unsafe fill in a "trust me" or a "manual override" or whatever. Something that tells you that the programmer had a reason to override the borrow-checker. If they are cool they tell you why the thing they did is indeed safe and sound code.
Obviously, there are some cases where it makes sense to use an unsafe block. However, I think there might be fewer cases then people might think.
As an example, both the popular generic self-referencing crates ouroboros and self_cell have had memory safety bugs in them in the past. (links at the end) Both of them were carefully reviewed by experienced rust developers before their first public release, and yet they still ended up with such bugs. Admittedly, part of the issue is that both crates are trying to be more generic, so they have to be correct over a larger range of circumstances.
But still, these crates have one job, are both less than 1500 LOC, and they were carefully reviewed to ensure they did that one job before their public releases, and they still ended up having issues that were not caught. They might still have issues.
Thus, while it might be fine to use unsafe to state that your array of zeros is a valid utf-8 string without a runtime check, it's probably a good idea to twist yourself into a pretzel if the invariants are not trivial to prove and the overhead to maintenance/runtime isn't too high.
`unsafe` is the part where the compiler trusts you to uphold your own invariants, necessary to prevent Unsoundness. For example:
- unsafe fn get_unchecked(index) - compiler believes you will ensure index < length.
- unsafe fn set_capacity(capacity) - compiler trusts you will not set capacity to value that will cause UB. Even if its code boils essentially to set a field - which is safe according to Rust, but may invalidate other invariants preserving soundness.
They simply wish the actual kernel developers just surrendered & weren't in the way of new Rust code. Maybe if these guys wrote C for a living some 10 years or so, became maintainers in their own right, and THEN brought these ideas forward—they would have the chance. But you can't come to the other people's projects, and seriously expect them to just nod ahead to everything you have to say, surrender your concerns, and act like they owe you sommat.
To my knowledge most if not all of these people driving Rust adoption in Linux are seasoned Linux contributors and/or maintainers. They are not outsiders "coming to other people's projects".
> To my knowledge most if not all of these people driving Rust adoption in Linux are seasoned Linux contributors and/or maintainers. They are not outsiders "coming to other people's projects".
Not in this case. It's the Rust evangelist who is the newcomer. FTA:
> Almeida said that he is not trying to keep the C API static; his goal is to get the filesystem developers to explain the semantics of the API so that they can be encoded into Rust.
The responses from the kernel team members to the proposal seem reasoned and mature to me:
> In addition, when the C code changes, the Rust code needs to follow along, but who is going to do that work?
> As the C code evolves, which will happen more quickly than with the Rust code, at least initially, there will be a need to keep the two APIs in sync.
> The object lifecycles are being encoded into the Rust API, but there is no equivalent of that in C; if someone changes the lifecycle of the object on one side, the other will have bugs.
> Encoding a single lifecycle understanding into the API means that its functions will not work for some filesystems.
> Part of the problem, Ted Ts'o said, is that there is an effort to get "everyone to switch over to the religion" of Rust; that will not happen, he said, because there are 50+ different filesystems in Linux that will not be instantaneously converted.
> Bottomley said that as more of those semantics get encoded into the bindings, they will become more fragile from a synchronization standpoint
> But Ts'o pointedly said that not everyone will learn Rust; if he makes a change, he will fix all of the affected C code, but, "because I don't know Rust, I am not going to fix the Rust bindings, sorry".
> Not in this case. It's the Rust evangelist who is the newcomer. FTA:
From a quick search, I've found that the person is somewhat active in kernel commits over the last four years (mostly but not all rust related from what I see) and is involved in some lkml stuff and some commits over a decade ago. Not sure if this makes him a newcomer or not, just wanted to provide a bit more context.
This is case-in-point; bcachefs maintainer is merely _entertaining_ the ideas proposed by the Rust evangelist, with the express intent of exploring alternatives... and suddenly it's enough for "the movement" to co-opt him into the "proposal" [to include Rust in the FS subsystem], it seeems. Are Rust supporters really as desperate so-as to co-opt ANY interest in the subject?? This toxicity is not helping anybody.
Kent Overstreet is the bcachefs maintainer and he's extremely pro-Rust. He has in fact talked about wanting to move bcachefs to Rust, and the userspace tools for bcachefs are already written in Rust.
He's been participating in the mailing list discussions about using Rust / providing Rust APIs for the FS subsystem.
I don't know who you're confusing him with, but you're confusing him with someone else.
I'm not sure what you are saying. Maybe the first proposal isn't the best one, so some exploration is warranted.
Is Kent an unwilling pawn in the game of getting Rust implemented in the Linux kernel? Or is he not serious enough about getting it in that his support should not be considered?
From what I've seen it reads to me Kent would be very happy to implement bcachefs in Rust in the Linux kernel. Bcachefs-tools does make use of it.
Kent has been really vocal about writing bcachefs in Rust in the IRC channel. They even started some work already, but decided to wait until the common abstractions are ready and merged.
> But they don't want to be writing file systems; instead, the only goal that matters to them is getting to the heart of the most popular OS, so as to secure some longterm success.
Wrong final word: security. In the war against remote exploits, harden the most widely used target first.
Rust only exists because getting people to reliably and consistently write secure C++ proved impossible.
(yes I know C++ is a much larger and more complicated language than C)
The only people to "hate" on Linux are the Rust community; in fact, they genuinely DESPISE the Linux maintainers for allowing themselves to be so brazenly exploited over the years. This is akin to how communists despise the workers.
Now, as for me: I respect Rust, not hate it, and only sympathise / pity the wider Rust movement. I believe their resources are much better spent someplace else: NOT bickering over decades-old operating systems and getting into the other people's codebases (this is what pleading for "common abstractions" is, really.) Had they learnt to stop competing for popularity and recognition, they would be very successful in validating the borrowing hypothesis. The conviction is not there: had there been conviction, heart, and commitment, they wouldn't bother with old codebases, and would instead make something special.
P.S. I don't require hate to be superior, my nature is sufficient to that end.
This is a common misconception; like every movement of "revolutionary" modus, it likes to over-represent its supporter base & amplify the chosen ambassadors. So whenever some kind of concession, or endorsement is made—it's immediately read, and amplified as indicative of a greater support, and/or change.
Both Windows and Android are shipping, today, with meaningful components written in Rust. Amazon S3 and Lambda are built on top of Rust. Apple is hiring Rust developers and they post about it on this platform [https://news.ycombinator.com/item?id=40849188]. Dropbox and Discord backend services are written in Rust. Cloudflare uses Rust very extensively in their infrastructure, which means that a large fraction of global internet traffic passes through routers and servers written in Rust. The UEFI firmware implementation of the next Surface products by Microsoft is written in Rust.
You are simply incorrect. Instead of arguing I will suggest that you do a slight modicum of research into who is using Rust and for what. While it won't be comparable in omnipresence with C and C++ for a long time, it is widely-enough used that there is a near-zero chance that you are not already using some tool or service that directly or indirectly uses Rust for some significant purpose. It is not a "forum and hobby project language". The list I just provided is also by no means complete - Shopify, Disney, Facebook, Firefox... and many others... also use Rust.
"According to Weston, Microsoft has already rewritten 36,000 lines of code in the Windows kernel in Rust, in addition to another 152,000 lines of code it wrote for a proof of concept DirectWrite Core library, and the performance is excellent with no regressions compared to the old C++ code. He also called out that “there is now a syscall, in the Windows kernel, written in Rust.”
Whatever experience you have is out of date with the current reality. Not only is there interest in using Rust in these core areas, but it has already started happening.
Thanks for eloquently responding to the GP comment... My own thoughts have been with Microsoft, Apple, Mozilla and Amazon actively backing Rust, it is definitely not something that will just go away.
Personally, I've only done surface level things (API middle tier dev) with a few different Rust frameworks (Axum, etc) and it's been relatively nice for the level of performance and low overhead compared to Node, C# and others. And what lower level code I've read has been particularly pleasant to come to understand.
While doing something like a global cache in Rust feels awkward as all hell, many other patterns just feel really nice to use. I like the semantics of the language itself. I do hope that certain enterprise patterns typical in Java and the C# communities don't come into play in Rust though.
> Rust kids need to quit tricking other entry level aspiring OS devs into wasting their time learning this language.
In that case, C/C++ developers need to quit tricking the rest of the world that C/C++ is a suitable language for anything security related and - for commercial
products - take responsibility for the economic and social impact for the data breaches due to memory safety issues.
(I really don't care if it's Rust, Java, C#, whatever.)
Hmmm. Is this serious or facetious? Or could be either, depending on the response? There already is rust code in the Linux kernel (some drivers), afaik.
Linus strategy on Rust is genius, albeit immoral. — Don't engage the movement head-on, make concessions where it doesn't matter. — Nobody wants to write drivers? No problem, have THEM write the drivers where the impact is minimal. I believe, if Rust people really understood how they're being used exactly, they wouldn't bother with it, and would go on to write more impactful code. And yet, Linus had managed to execute this strategy perfectly; the insult is subtle enough not to cause major injury.
I seriously doubt it's meant as an insult so much as to minimize near term impact in case there are (and likely will be) mistakes to the larger ecosystem. Creating clearer separations for where Rust can make more sense initially is important. Not just for Rust, but C/C++ and other future languages all around.
The file system is an area where Rust can make a lot of sense, similar for network drivers. Points of interaction with underlying hardware and external systems where well defined controls are all the more important and widely interacted with.
I would be surprised, if within a decade a lot of the use of OpenSSL isn't displaced with rustls across a lot of applications even if not written in Rust directly.
> Linus strategy on Rust is genius, albeit immoral. — Don't engage the movement head-on, make concessions where it doesn't matter. — Nobody wants to write drivers? No problem, have THEM write the drivers where the impact is minimal.
Using telepathy to explain someone’s unstated intention to undermine some programming language’s use in the kernel with this House of Cards plotline makes you look insane btw.
Someone's gotta get the word out, I'm seriously sick of all these ridiculous LARPers trying to magic Rust into existence
Rust is a joke, it's a complete waste of time and effort to try and use it. It's the EU cookie law of native code - well-intentioned nonsense that doesn't work at all in reality
Perhaps a better approach would have been for Linus to design his own backwards-compatible and safer fork of the C language, and have the kernel gradually rewritten in that.
He's already written - with a considerable amount of collaboration of course - the world's most popular kernel and the world's most popular source control system. I expect he'd be able to do the same for a new and improved systems language if he put his mind to it.
The safety is achieved by eliminating constructs which cannot be proven to be safe. Additionally, Rust-style safety involves adding more information explicitly to the source which otherwise has to be kept in the programmer's head (or externally like sel4): object lifetimes, lock rules (see original article), etc.
At best you end up with "first wrap all your original code in 'unsafe' and then gradually move the safety boundary", but even that is very difficult.
Not advocating for this, but you could also imagine a C superset where all of the new features only apply in 'safe' blocks, which would be backwards-compatible, and likely safer-in-practice.
A C variant that e.g. defined OOB access to segfault (or panic in this case) would be strictly safer while being fully compatible with all valid C code. Not that I'm advocating for such a C variant but your snide retort is simply wrong: there is plenty of room for making C safer without reinventing the wheel.
