Switching to a more modern topic, the introduction of the Rust language into Linux, Torvalds is disappointed that its adoption isn't going faster. "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." On top of that, Torvalds commented, "Another reason has been the Rust infrastructure itself has not been super stable."
AI
"When AI came in, it was wonderful, because Nvidia got much more involved in the kernel. Nvidia went from being on my list of companies who are not good to my list of companies who are doing really good work."
Another developer here who writes in C and C++, same. I think a lot of people have this complaint. I'm sad about it because what Rust provides in principle sounds great. The language is hideous though, and I really don't want to write anything in it.
The return type of that get_or_create_inode() function is:
Result<Either<ARef<INode<T>>, inode::New<T>>>
I'd say that's a pretty good example for 'hideous'. It looks like some of the worst C++ code I've seen and then quickly tried to forget. If stuff like this ends up in the Linux kernel I would be pissed too as a Linux kernel greybeard.
I agree that it could maybe use some new types, but it also does kinda get to the heart of this: I’ve never used this kernel API before, but I can say “oh, this function may error out, but if it doesn’t, it gives me either a new inode or a reference (I’m assuming that’s what ARef is) to an existing one. That’s a lot of valuable information, at a glance.
> That’s a lot of valuable information, at a glance
...if you know how to decode it. That example looks like one of those C++ SFINAE hacks, e.g. trying to bend the template/generics syntax beyond what it was designed for.
If Rust APIs want to go that way (of overly expressive strong typing) then Rust really should offer a better syntax for describing such types. But it's not even clear to me if such strongly typed APIs are even a good idea. From my experience in C++ and (especially) Typescript with similar APIs, it's a PITA to work with in real world projects, and on both sides of the API.
I mean, it’s very straightforward generics. There’s just nesting, each of these types has one or two parameters and that’s it. I’m not sure there’s a simpler way of communicating the same thing.
But I also think that I wouldn’t design an API that works like this in Rust natively; this is adapting a signature from C rather than doing the API you’d want if you were creating something from whole cloth.
I also believe that static types are very different based on the language; I’d rather write Ruby than Java, but I’d rather write Rust than Ruby. More advanced type systems tend to actually pull their weight, whereas simpler ones don’t give enough juice for the squeeze, IMHO.
IMHO there's a pretty wide range between static weak typing and static strong typing even within a single language.
Going too far into either extreme has more downsides than upsides - yes, strongly typed code will be more correct because the types might catch usage 'logic errors' during compilation, but also harder to maintain when requirements change (because strong types tend to creep into every little corner of a code base - and they are extremely rigid by design making the code which uses them also very rigid).
My goto example where I burned myself in the past is splitting a vec4 into point and vector types.
It totally makes sense from a theoretical design pov (e.g. `point + point` would be illegal, while `point + vector` or `vector + vector` are allowed). But in reality such code is awkward to work with for many little reasons, and the enforced correctness pretty much never catches bugs, it just adds pointless busy work when the code needs to change.
I agree that something like "over-typing" exists. But where it starts is imho very context dependent.
For the lowest level (e.g. an OS) you really want an extremely strict regime. Bugs are "simply not allowed"…
For application level code I think it depends. Nobody would finish anything if the requirement would be to formally verify all your code.
The other thing is: How far you can get before "over-typing" starts is also dependent on the language and how powerful it's type inference system is. Rust is quite weak in this regard.
In a language where the compiler can pass context for you one can have very strong guaranties without making working with the code too awkward. Of course, changing the code will need work. But that's the whole point of type systems: If you change something the compiler will tell you any places where something needs repair. In less strongly typed languages you can just pray that your tests are good enough to cover the changes.
In case of changes a good compiler will even rewrite the trivial cases for you if you ask, and just leave what really needs human oversight. But such automatic rewriting (with the guaranty that nothing went wrong!) works only if you had very strong types in the first place.
If I knew the answer I would design programming languages ;) Replacing `Either<this, that>` with something like `this | that` like in Typescript might be going into the right direction though. Zig has similar syntax sugar for Rust's Result<> and Option<>. Such things are so fundamental that they should be part of the language instead of the stdlib IMHO.
> Don't see how this is a Typing issue, sounds more like API issue
Designing an API is a typing issue, because an API is essentially nothing more than a list of types.
Here `Result` is very likely not the standard library type, because `std::result::Result` has two generic types for Ok and Err. It will be a partial alias to `Result<T, Error>` where `Error` is used throughout the entire code base to simplify the error handling. (The same pattern occurs in `std::io::{Result, Error}` in the standard library.)
Making `Result` a built-in syntax will disallow such freedom, and Zig has whole dedicated features to tackle problems solved by having `Result` just a normal type. Everything here is just a trade-off and both Rust and Zig have reasonable solutions for their use cases.
> Replacing `Either<this, that>` with something like `this | that`
That's not the same.
The first one is an ADT instance with exactly two cases, whereas the other is an arbitrary union type.
The difference is when you pattern match on them. In the first case the compiler can statically verify that you handled all (two) cases. In the second case you can deconstruct the union, but you're not forced to handle all cases, simply because there are no know "all cases"; you could have arbitrary unions of any amount of things. (Of course the compiler could create for any usage of an union type some synthetic ADTs behind the scenes and check exhaustivity on them, but this would explode pretty quickly, I think, because of code bloat and compile times. Also that's not the expected behavior of union types in general).
> Designing an API is a typing issue, because an API is essentially nothing more than a list of types.
It's more a list of signatures, and some interaction protocol on top of that. (Frankly not expressed in types usually. We don't have simple ways to use things like session types still).
The types used in your signatures can be as specific or general as you want. It's the choice of the API designer. There is no issue with typing as such. You could just declare everything being a function from `Any => Any`… That's of course as bad as having so specific types that there can be more or less only one object shape that fits it. Classical over-typing, and that's imho just bad API design…
There is no fundamental way to simplify that further. If you omit angle brackets and use whitespaces instead then you will get a Haskell-like syntax which is even more horrible:
Result (Either (ARef (INode T)) (inode::New T))
Maybe a single generic argument shouldn't need any parentheses. It would imply that `a b c` should be parsed as `a (b c)`, which is not super obvious due to the inverted order. ML instead swaps the entire order, so that `a b c` is sensibly `(a b) c` but here `b` and `c` would be base types. That yields the following:
(T INode ARef, T inode::New) Either Result
I think this is indeed slightly better than the current Rust syntax, but any C developer will have hard time adjusting their brains to this order. This and the very existence of C++ prompted Rust to use the same syntax as C++ (the very early version used `A[B]` instead), but otherwise Rust types are much more predictable than C++ due to the lack of compile-time metaprogramming [1].
The fact that Haskell is not very different from Rust in the type syntax complexity shows that this type is just fundamentally "complex", because it is composed of multiple composable types. (I will personally avoid `Either` because I think an explicit enum is better here, but otherwise everything is independent from each other.) And an equivalent C function will do the same thing but without any type declaration and ad-hoc error code and/or convention, which never works well in practice.
[1] Some Rust crates do still attempt this, like the `typenum` crate, but I would not recommend them in general because they are really awkward to use.
Maybe it's because I'm working a lot with V8, but that looks quite a lot like most C++ generics I've been looking at lately. Especially when working with concepts, it's easy to end up 5 or more nested angle brackets in.
Rust generics are much underpowered than C++ templates in order to make them an integral part of type system. Many practical C++ programmers avoid excessive template magics for that reason and also for simplicity, and Rust's restriction is essentially its codification.
I didn't watch any other talks of this conference, but it looks to me as part of the issue here was that the presenter didn't explain basic (ML) types upfront. Maybe they did in other talks earlier, IDK.
If you never seen such types before it may look intimidating. But if you ever seen any ML style language the type of said function looks actually very ordinary. It does not use any really more complex concepts, it's just regular nested generic types. Pretty standard stuff.
Thanks for sharing. This makes a lot of sense to me. I’m not close to kernel development but any change to an established entity impacts the interest of people in it. So a primary obstacle change encounters is that it may diminish power people obtained in the establishment.
These people, while well intentioned in pushback, have difficulty separating benefit to the entity and benefit to themselves. So it takes a lot of work to impact change, and I understand the distance it has from normal technical work.
It's inevitable in any organisations when dealing with change. Identifying resistance and coming up with strategies to overcome is a key part of change management. Telling people their reaction is "kneejerk pushback" usually does not help ;)
It's probably more difficult to handle in open source than in a company because authority less powerful and it's more difficult to wave both carrots and sticks...
At a talk presenting a personal project? Do you also feel it's OK to go to talks on Java projects to make statements like "Well, why didn't you write this in Go? It's a better language that serious developers are using and nobody will want to contribute to your dumb project using java"
Yup, anyone defending this behavior needs a screw tightened.
The dev "pushing back" was being an asshole probably because of deep insecurity of gasp there being other programming languages than C.
Literally rust is currently being proposed for maybe new drivers and basically nothing else ATM. Nobody is suggesting rewriting code in rust or forcing people to learn rust. It is literally just "Hey, might be nice to write this driver for my mouse in a memory safe language".
He did a presentation on making a fs in rust, the response from this dev was "we won't be converting to your religion. We are going to continue modifying c code and your dumb rust code will always be a second class citizen."
Literally just hostility for hostility sake. He wasn't proposing to rewrite everything in rust. He wasn't proposing that everyone learns rust. He was just giving a freaking presentation on making a rust fs that integrates with the kernel and was immediately trashed for spreading religion or whatever.
What was literally said didn't include the words "always" or "your dumb rust code". From the subtitles with slight manual fixes:
> I suspect part of the problem here is you're trying to convince everyone to switch over to the religion as promulgated by rust and the reality is that ain't going to happen because we have 50 plus filesystems in Linux, they will not all be instantaneously converted over to rust. Before that happens we will continue to refactor code because we want to make the C code better. If it breaks rust bindings, at least for the foreseeable future the rust bindings are a second class citizen and those file systems that depend on the rust bindings will break and that is the rust bindings problem, not the file system community at large's problem and that's going to be true for a long long time, okay, and I think we just simply need to accept that
That seems rather technical to me. To put words into their mouth because they had a snarky tone, or claim the presenter was "immediately stacked for spreading religion or whatever" hardly is.
They literally said "spreading your religion" at the very start of their critique. I think I'm correctly reading the tone of the rest of the comment even if I didn't verbatim quote them.
From the closed captions with minor editing. In response to "we are going to provide API bindings"
> I suspect the problem here is you are trying to convert everyone to the religion as promulgated by rust and the reality is that ain't gonna happen. Because we have 50 plus filesystems in linux and they will not all be instantaneously converted over to rust. Before that happens we will continue to refactor code because we want to make C code better. If that breaks the rust bindings at least for the foreseeable future the rust bindings are a second class citizen. Those file systems that depend on the rust bindings will break and that is the rust bindings problem not the file system community at large problem. And that's going to be true for a long long time, OK. And I think we just simply accept that right because the answer you are not allowed to refactor C code because it would break 5 critical file systems that distros depend on is like not a star, OK.
> They literally said "spreading your religion" at the very start of their critique.
And that critique is near the end of all the people who asked questions or made comments. So no, the presenter wasn't "immediately stacked" when making that presentation.
Linus has the wisdom to see the writing on the wall - the kernel is becoming too
complex to be maintained and extended by newcomers; the pool of C ninjas that can handle it reliably is diminishing. This kind of foresight is what makes Linux trustworthy in the first place. A lot of current individual contributors lack that vision and fail to understand the reason for introducing what they see as unneeded complexity.
The other reason Linux is trustworthy because of the technical meritocracy culture. But since Rust is not a technical choice, as Rust cannot per-se do things that are impossible in C - you can do anything in C - the introduction of Rust falls outside the parameters of the regular rough-but-mostly-fair Linux exchanges. This leading to toxic reactions from the less socially-abled.
> But since Rust is not a technical choice, as Rust cannot per-se do things that are impossible in C - you can do anything in C
Have anything in particular in mind? It's been my understanding that Rust actually can do everything C can, but the additional safety guarantees imposed by the type system make it a bit harder.
> Lastly, I'll leave a small, 3min 30s, sample for context here:
https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force
anyone else to learn Rust nor prevent refactorings of C code.
A redditor pointed out [0] that this is exactly what they would do to sink Rust adoption. Even if you agree with the substance of the argument, the delivery is rude and unhelpful. I hope this resignation is a wake-up call, and much of the onus is on C devs to be more collaborative.
Why do C devs even have to be 'collaborative' about Rust modules? The latter would typically ingest C APIs, most likely via bindgen, making C code the "source of truth" about what the API is - because Rust modules are self-contained and C is the only stable ABI that Rust supports. All the type-checking smarts that the video talks about are purely on the Rust side. If a new 'raw' low-level C API is needed to build better smarts on the Rust side (which seems to be what's involved in some of the fs proposals) that can just be a self-contained proposal, with very lightweight changes on the C side of the code. This whole thing looks like a tempest in a teapot to me - and to be clear, this absolutely includes the Linux dev's complaints, which are extremely poor form.
That burden would fall on Rust maintainers. If the Rust code goes unmaintained and nobody is around to pick it up, it just gets dropped from Linux releases that rely on the up-to-date C API.
The Rust maintainers said they would maintain the Rust bindings. But wouldn't it be nice to have a heads up that the bindings might break? Or whether assumptions have changed? Or even what the assumptions are?
It's a little tough to build a safe abstraction layer on top of C or encourage maintainers to stick around with a hostile "that's a _you_ problem" mentality or inaccurate rhetoric that Rust are trying to force their religion onto the C devs.
For those who don’t or can’t watch the video, or want to know who is saying what, here’s an LWN article describing what happens in that section of video.
Good news for whom? The mental safe space of old time kernel developers? Or good new for users who will continue to have to deal with kernel panics and other memory issues.
> users who will continue to have to deal with kernel panics and other memory issues.
I have not seen many of those in my close to 32 years of involvement with Linux. In the beginning of the project they did occur 'every now and then' but once Linux got past v1.2 or thereabouts they're about as rare as hen's teeth. If Rust ever becomes widespread enough for kernel developers to pick it up with ease it will be a welcome addition but until such a time I prefer for the project to remain C-focused so as not to close out a large fraction of the potential developer base. If that means that some 'competing' kernel gets written in Rust and takes over from Linux that'd be fine by me as well, may the best [1] kernel win.
I admit it's not often I see a direct panic. But I do see bugs caused by memory issues relatively often. In fact two weeks ago I made a patch for a memory issue in a wifi driver that caused it to drop connections. The long list of CVE is more direct proof though. By far most of them are memory safety issues.
Suggesting making a new kernel is just total FUD. This is a multi decade project. It's like saying to a person who want some legislation in their country to change "why not make your own country, may the best country win". It's just so far removed from reality I'm very surprised I have seen this argument more then once.
> Suggesting making a new kernel is just total FUD. This is a multi decade project.
Linux started as a hobby project of a single student and just a few years later it was already possible to build a full-blown UNIX desktop system with Linux as kernel.
Why should that not be possible to replicate today? Especially with modern development tooling and a big and motivated language community?
> Why should that not be possible to replicate today?
What is missing is the user base! When Linus started his project, many people knew Unix in their professional life and were disappointed with what the market (M$) was proposing for the personal computer world.
Today, no such multitude is waiting for the next Linux.
Linux may not be perfect, but it's definitely good enough.
Ideally such a Rust kernel project would implement a drop-in-replacement for the Linux kernel, so that Linux distros could select between the original Linux kernel and the Rust 'imposter'. That way the users would already be there. It would just be a detail like GNOME vs KDE, X11 vs Wayland, or glibc vs MUSL.
What was acceptable in 1995 is not what is acceptable today. Linux took literal decades + in the billions of dollars to build. It's ridiculous to suggest a rust project can just catch up to that with a few developers and no funding in any sane timespan. If you think it's reasonable to suggest "Just outcompete this heavily and continuously developed 34 year old project which has the backing of the largest technology firms on earth" I really don't know what to tell you. We live in different realities.
That doesn't even begin to touch on the problem that linux came at just the right time.
Sure it's foolish, but so was trying to 'outcompete' industry giants like IBM and Microsoft in the early 90s with a hobby kernel. That didn't stop a certain Finn from just writing a kernel anyway. If that project hadn't taken off, then maybe another one, or another one.
Replacing any substantial parts of the Linux project with Rust also would be multi-decade effort, most likely more effort than forking off a separate evolutionary branch (which is probably the most realistic option). Such forks happened all the time in the history of UNIX.
It was considerably less foolish then, then now. It's not even close. The complexity of the operating system kernels has more then increased 50x over the last 34 years. It's not even remotely comparable.
No one wants to replace substantial parts of the linux project with Rust. This is a straw man, and the same bad faith argument the set in their ways kernel greybeards are making. People just want to be able to write green field drivers in Rust.
Users should only need to care about what happens in user space. And the most important promise of Linux is "don't break user space". The kernel's programming language is literally just an internal implementation detail, irrelevant for Linux users.
The security vulnerabilities that affect my PII kinda contradict the idea that the kernel is an implementation detail. It’s not an implementation detail if I do, in fact, have to care about it.
The wish of the lead developer is for Linux development to continue beyond the life of the current maintainers. Training to be a competent system programmer using C is unnecessary long and painful. There aren't enough C hackers coming up anymore. The Rust learning curve is a bit sharper than C for the first weeks but gets you to a competent and non-dangerous state much more quickly after that.
This problem is not expected to be solved by current maintainers. They're just asked to make room for the next generation. "It should hurt you like it hurt me" is not an acceptable response.
If C is actually "very simple", you should be able to write a working interpreter for C in a short time, say, one week. (I would assume that you know how to write an interpreter in general, of course.) Can you?
> Does the proverbial rust programmer who doesn't know C even exist?
I have seen enough Python or JS programmers learning Rust without having any working knowledge about C. Of course Rust is not an easy language to learn for them, as they have to deal with a concept of explicit memory and lifetime that have no equivalent in Python or JS, but otherwise I didn't see any complication specific to Rust.
The argument was "I don't want to learn Rust, I'm not going to learn Rust, and if you put a non-C language in the codebase, I'm going to break it without giving a shit". Not sensible in the least.
I heard more like: "We have been borking like this for 26 years now and the result is amazing. If you want to introduce a new API for a couple of eventual use cases, you are welcome to do so, but don't event think to impose any additional burden on us."
The rust guys were just asking for semantic information about the current C apis so they could try to encode them into the type system.
All they got in response to that were made up problems of them supposedly forcing everyone to adopt their religion, rust being too OOP or other nitpicks that had nothing to do with the issue the presenters were trying to talk about.
Nobody even answered their questions, people which obviously didn't even look at rust for more than an hour gave their opinion on why what they're doing is bad and destined to fail. It was rude, tone-deaf and not a single technically sound argument was actually made.
I love linux and I'm fine with the maintainers deciding to use C if they want to, but the behavior by the old guard here was actually appalling and reeks of deep insecurity and inability to communicate.
Since when is Rust a requirement to help Linux development? Only an utter idiot could think that such a big and successfully community would put any effort in addressing any issue that is not posed in their natural language!
If you want to introduce Rust into Linux, you learn C, you learn Linux, you add and maintain whatever you want.
> Since when is Rust a requirement to help Linux development?
It's not and it shouldn't be, but it is most definitely required if you want to criticize it's integration into the kernel due to its supposed flaws/merits in a "technical" discussion.
Nobody is forcing anyone to learn rust, the RiL folks are fine with maintaining bindings and handling the fallout of C API changes. They didn't even get to say that, because they were shouted at for asking a question.
> If you want to introduce Rust into Linux, you learn C, you learn Linux, you add and maintain whatever you want.
Which is basically exactly what the RiL community is doing. In the posted video you can see them TRYING their best to learn about the undocumented invariants of a C API and getting nothing but flak for it for completely made up reasons. I might be hard to understand, but many of the strongest advocates of rust know C well and are opposed to using it themselves for good reasons.
The folks maintaining C API don't have to care much about the rust part, except maybe giving a friendly heads-up when they change API's they depend on, like you would in any kernel development work where you are impacting another subsystem.
Apparently this is too much to ask from some of these C grandpas.
While these guys have undoubtedly made great contributions to Linux and FOSS and I'll be forever thankful for that, some of their behavior towards the RiL community has been appalling and petty. They have been resistant to any sort of change, even if it does not impact them at all, are quick to criticize without any attempt at understanding the efforts and benefits of Rust integration or even making any technically coherent argument. Constructive criticism and open discussion is important, but it should be based on accurate information and a willingness to learn instead of knee-jerk reactions and reacting to people wanting to learn about the API of your subsystem with outright and unwarranted hostility.
> It's caused a lot of trouble so far and for what?
The "for what" seems pretty obvious, no? It's the same reason you would use Rust over C in any other project. Memory safety and more modern PL features.
Kernel code shouldn't need a 'good and fast' allocator though, since preferably it shouldn't heap-allocate in the first place, or at least not frequent enough that allocator performance matters.
> Well, maybe that's exactly what should happen. Maybe rust should have never been allowed in the kernel in the first place.
Can you clarify these two sentences? You say there should be a memory-safe kernel, and then you say Rust should never have been allowed, which is the opposite.
Same opinion here, have all this giant proRust energy and put it behind a few Rust kernels, combining the Rust super powers with latest kernels architectures and have at least one Rust kernel that is not UNIX but something super modern.
I would have expected more then one Rust kernels.
It kind of seems that Rust community is missing the ability or the desire to implement a kernel and would like the Linux kernel devs to do the work for them.
There are tons of embedded kernels, Android uses Rust in their Linux, Windows already ships Rust in their kernel. Just because someone mentions one project doesn’t mean it’s an exhaustive list.
I mean notable projects, I do not consider toy projects in this.
Just because someone pushed some Rust into a kernel it does not make that kernel a Rust kernel, this is the issue with Rust community , hyping the fact that some devs managed to pushed a few lines of Rust in some kernel as some big victory.
Even Mozilla gave up on making a browser in 100% Rust, it seems that rewriting in Rust is not that easy and people like to talk then do the work.
I'm not talking about toy projects. I'm talking about real, used in production kernels. One of those embedded ones is used by my employer, for example.
> people like to talk then do the work.
There are tens of millions (I'm being conservative here, not sure I'd claim 100M) of Rust code running in production, at many very large tech companies. I feel like you have an opinion and are trying to fit the facts to it, rather than the other way around.
So why are you naming that non toy kernel your company uses in many devices in production?
I did not say that there are not tons of millions of Rust lines of code used in production, I wish there would be a modern kernel for PCs not some micro/nano kernel for some board. I see it a big waste to push Rust into Linux or Windows kernels instead of those competent developers writing that new modern kernel, it feels like they are forced to work on Linux/Windows so they want to have fun with Rust at work. If Rust is so superior then you just need to start the kernel, prove is super fast and super safe and Big Tech will put the money so they can use it on their servers, Like why would Netflix not use the super kernel written in Rust ?
"just" writing a production-grade Linux equivalent would take decades. Some people are working on such projects, but those will take a long time, if ever, to mature, whereas improving Linux means making positive change today. Both things can be pursued in parallel, by different people. It's not an either/or.
Good luck to this new kernels, my guess is that you do not get any speed boost from using Rust, sure you might get fewer bugs but since we do not have a basic kernel and OS yet with a GUI that I can run at least in a VM tells me that something is not matching the hype, maybe the constant fighting with the type system make adding new things or updating existing code super slow.
I honestly wish to see modern OS as a competition to the decades old Linux and Windows.
What they're getting at is that it probably would have been better if the Rust people had started their own kernel project, cherry-picked the pieces of Linux they wanted, and then made their own new thing without three decades of obsolete Unix/Linux baggage. This would mean they could spend their time actually writing software and and less time trying to convince a bunch of C programmers that their time is at an end and their influence is counterproductive.
Describing it as “the Rust people” as though they are separate from the a Linux project is a rhetorical sleight of hand to imply some sort of outside invasion.
These are a Linux kernel people who want to use Rust. Writing a new kernel would be fundamentally different than working on Linux.
Also, they are “writing software,” and have been for a long time now. This isn’t just some random arguing on mailing lists, this is actual patches, with folks like Asahi and Android writing real meaningful drivers on top of it.
They are separate from the other kernel developers, but not in the negative way you seem to want to assign to me. They aren't an outside invasion, they are a cultural revolution.
They may want to work on Linux but it's clear that the rest of the Linux developer community does not want to allow it, for reasons you are free to interpret as positive or negative as you see fit.
They want to write software, and they are getting somewhere, but they are restricted by the attitudes of the rest of the Linux kernel people fighting against them, so they are sucked into constant flamewars and divisive infighting. All just so they can say what they are working on is "Linux".
At the end, the question must be asked whether or not Linux and its decades of Linux/Unix baggage are worth holding back the progress represented by a kernel that is Rust from top to bottom, and written with safety and security as its top priorities from day zero instead of decades after.
There are people interested in making the Linux kernel more memory safe using Rust. And from what I am observing they aren't interested in a hard fork and are looking for collaboration.
These are different populations.
Contrary to what Theodore Ts'o is ignorantly saying, Rust is not a religion.
Rust
Switching to a more modern topic, the introduction of the Rust language into Linux, Torvalds is disappointed that its adoption isn't going faster. "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." On top of that, Torvalds commented, "Another reason has been the Rust infrastructure itself has not been super stable."
AI
"When AI came in, it was wonderful, because Nvidia got much more involved in the kernel. Nvidia went from being on my list of companies who are not good to my list of companies who are doing really good work."
IMHO, as a C developer, I love Rust's features but the syntax is terrible.
Another developer here who writes in C and C++, same. I think a lot of people have this complaint. I'm sad about it because what Rust provides in principle sounds great. The language is hideous though, and I really don't want to write anything in it.
What things are hideous about it and what would you rather it look like?
That video snippet which was posted by that former Rust/Linux maintainer has an excellent example:
https://www.youtube.com/watch?t=1529&v=WiPp9YEBV0Q&feature=y...
The return type of that get_or_create_inode() function is:
I'd say that's a pretty good example for 'hideous'. It looks like some of the worst C++ code I've seen and then quickly tried to forget. If stuff like this ends up in the Linux kernel I would be pissed too as a Linux kernel greybeard.
I agree that it could maybe use some new types, but it also does kinda get to the heart of this: I’ve never used this kernel API before, but I can say “oh, this function may error out, but if it doesn’t, it gives me either a new inode or a reference (I’m assuming that’s what ARef is) to an existing one. That’s a lot of valuable information, at a glance.
> That’s a lot of valuable information, at a glance
...if you know how to decode it. That example looks like one of those C++ SFINAE hacks, e.g. trying to bend the template/generics syntax beyond what it was designed for.
If Rust APIs want to go that way (of overly expressive strong typing) then Rust really should offer a better syntax for describing such types. But it's not even clear to me if such strongly typed APIs are even a good idea. From my experience in C++ and (especially) Typescript with similar APIs, it's a PITA to work with in real world projects, and on both sides of the API.
I mean, it’s very straightforward generics. There’s just nesting, each of these types has one or two parameters and that’s it. I’m not sure there’s a simpler way of communicating the same thing.
But I also think that I wouldn’t design an API that works like this in Rust natively; this is adapting a signature from C rather than doing the API you’d want if you were creating something from whole cloth.
I also believe that static types are very different based on the language; I’d rather write Ruby than Java, but I’d rather write Rust than Ruby. More advanced type systems tend to actually pull their weight, whereas simpler ones don’t give enough juice for the squeeze, IMHO.
IMHO there's a pretty wide range between static weak typing and static strong typing even within a single language.
Going too far into either extreme has more downsides than upsides - yes, strongly typed code will be more correct because the types might catch usage 'logic errors' during compilation, but also harder to maintain when requirements change (because strong types tend to creep into every little corner of a code base - and they are extremely rigid by design making the code which uses them also very rigid).
My goto example where I burned myself in the past is splitting a vec4 into point and vector types.
It totally makes sense from a theoretical design pov (e.g. `point + point` would be illegal, while `point + vector` or `vector + vector` are allowed). But in reality such code is awkward to work with for many little reasons, and the enforced correctness pretty much never catches bugs, it just adds pointless busy work when the code needs to change.
I agree that something like "over-typing" exists. But where it starts is imho very context dependent.
For the lowest level (e.g. an OS) you really want an extremely strict regime. Bugs are "simply not allowed"…
For application level code I think it depends. Nobody would finish anything if the requirement would be to formally verify all your code.
The other thing is: How far you can get before "over-typing" starts is also dependent on the language and how powerful it's type inference system is. Rust is quite weak in this regard.
In a language where the compiler can pass context for you one can have very strong guaranties without making working with the code too awkward. Of course, changing the code will need work. But that's the whole point of type systems: If you change something the compiler will tell you any places where something needs repair. In less strongly typed languages you can just pray that your tests are good enough to cover the changes.
In case of changes a good compiler will even rewrite the trivial cases for you if you ask, and just leave what really needs human oversight. But such automatic rewriting (with the guaranty that nothing went wrong!) works only if you had very strong types in the first place.
How would you like Rust to describe such Types?
> a PITA to work with in real world projects, and on both sides of the API.
Don't see how this is a Typing issue, sounds more like API issue
> How would you like Rust to describe such Types?
If I knew the answer I would design programming languages ;) Replacing `Either<this, that>` with something like `this | that` like in Typescript might be going into the right direction though. Zig has similar syntax sugar for Rust's Result<> and Option<>. Such things are so fundamental that they should be part of the language instead of the stdlib IMHO.
> Don't see how this is a Typing issue, sounds more like API issue
Designing an API is a typing issue, because an API is essentially nothing more than a list of types.
Here `Result` is very likely not the standard library type, because `std::result::Result` has two generic types for Ok and Err. It will be a partial alias to `Result<T, Error>` where `Error` is used throughout the entire code base to simplify the error handling. (The same pattern occurs in `std::io::{Result, Error}` in the standard library.)
Making `Result` a built-in syntax will disallow such freedom, and Zig has whole dedicated features to tackle problems solved by having `Result` just a normal type. Everything here is just a trade-off and both Rust and Zig have reasonable solutions for their use cases.
> Replacing `Either<this, that>` with something like `this | that`
That's not the same.
The first one is an ADT instance with exactly two cases, whereas the other is an arbitrary union type.
The difference is when you pattern match on them. In the first case the compiler can statically verify that you handled all (two) cases. In the second case you can deconstruct the union, but you're not forced to handle all cases, simply because there are no know "all cases"; you could have arbitrary unions of any amount of things. (Of course the compiler could create for any usage of an union type some synthetic ADTs behind the scenes and check exhaustivity on them, but this would explode pretty quickly, I think, because of code bloat and compile times. Also that's not the expected behavior of union types in general).
> Designing an API is a typing issue, because an API is essentially nothing more than a list of types.
It's more a list of signatures, and some interaction protocol on top of that. (Frankly not expressed in types usually. We don't have simple ways to use things like session types still).
The types used in your signatures can be as specific or general as you want. It's the choice of the API designer. There is no issue with typing as such. You could just declare everything being a function from `Any => Any`… That's of course as bad as having so specific types that there can be more or less only one object shape that fits it. Classical over-typing, and that's imho just bad API design…
If you need a certain object shape, best require it in the API.
You can't be too specific there, because being as specific as possible has advantages: https://news.ycombinator.com/item?id=41409475
There is no fundamental way to simplify that further. If you omit angle brackets and use whitespaces instead then you will get a Haskell-like syntax which is even more horrible:
Maybe a single generic argument shouldn't need any parentheses. It would imply that `a b c` should be parsed as `a (b c)`, which is not super obvious due to the inverted order. ML instead swaps the entire order, so that `a b c` is sensibly `(a b) c` but here `b` and `c` would be base types. That yields the following:
I think this is indeed slightly better than the current Rust syntax, but any C developer will have hard time adjusting their brains to this order. This and the very existence of C++ prompted Rust to use the same syntax as C++ (the very early version used `A[B]` instead), but otherwise Rust types are much more predictable than C++ due to the lack of compile-time metaprogramming [1].
The fact that Haskell is not very different from Rust in the type syntax complexity shows that this type is just fundamentally "complex", because it is composed of multiple composable types. (I will personally avoid `Either` because I think an explicit enum is better here, but otherwise everything is independent from each other.) And an equivalent C function will do the same thing but without any type declaration and ad-hoc error code and/or convention, which never works well in practice.
[1] Some Rust crates do still attempt this, like the `typenum` crate, but I would not recommend them in general because they are really awkward to use.
Maybe it's because I'm working a lot with V8, but that looks quite a lot like most C++ generics I've been looking at lately. Especially when working with concepts, it's easy to end up 5 or more nested angle brackets in.
Yeah, but is that a good thing? Complex template magic is hardly one of the good parts of modern C++.
Rust generics are much underpowered than C++ templates in order to make them an integral part of type system. Many practical C++ programmers avoid excessive template magics for that reason and also for simplicity, and Rust's restriction is essentially its codification.
But it's not template magic. Not even something close.
It's just nested generic types.
How would you otherwise express all the constrains in a type?
Calm down with the bikeshedding. It’s just a complex C API and they wanted to convey the semantics concisely.
I didn't watch any other talks of this conference, but it looks to me as part of the issue here was that the presenter didn't explain basic (ML) types upfront. Maybe they did in other talks earlier, IDK.
If you never seen such types before it may look intimidating. But if you ever seen any ML style language the type of said function looks actually very ordinary. It does not use any really more complex concepts, it's just regular nested generic types. Pretty standard stuff.
In Rust you could also have things like:
That's indeed much more involved, even it doesn't use any deeply nested wrapper types.
But I think nobody would force such complex signatures on API end-users.
(Even there is of course also no magic going on. It's just the quite quite expressive type language in Rust).
Yup, Rust syntax is just the worst - except for all the other syntax proposals that have been made over time: https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html
Imho quite bad example.
Not even one tubo-fish. No multiple lines of `where` clauses. No (dyn) trait impl. Not even a lambda!
On top of that Rust's syntax is full of noise. Curly braces, semicolons, ugly angel brackets, `::` instead of points for namespaces, etc.
Rust is a quite good language on the technical level. But the surface syntax is really ugly.
Regretfully a major Rust for Linux maintainer just stepped down yesterday, saying he doesn't have the energy to keep dealing with the constant nontechnical nonsense: https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@...
I lack context. What is the “constant nontechnical nonsense”?
Kneejerk pushback from old timers C-only kernel devs.
Thanks for sharing. This makes a lot of sense to me. I’m not close to kernel development but any change to an established entity impacts the interest of people in it. So a primary obstacle change encounters is that it may diminish power people obtained in the establishment.
These people, while well intentioned in pushback, have difficulty separating benefit to the entity and benefit to themselves. So it takes a lot of work to impact change, and I understand the distance it has from normal technical work.
Asahi Linux’s (Distro targeting Macs) developer also recounts a similar experience. https://vt.social/@lina/113045455229442533
It's inevitable in any organisations when dealing with change. Identifying resistance and coming up with strategies to overcome is a key part of change management. Telling people their reaction is "kneejerk pushback" usually does not help ;)
It's probably more difficult to handle in open source than in a company because authority less powerful and it's more difficult to wave both carrots and sticks...
Well, as an uninvested observer I think it is okay to call it out.
At a talk presenting a personal project? Do you also feel it's OK to go to talks on Java projects to make statements like "Well, why didn't you write this in Go? It's a better language that serious developers are using and nobody will want to contribute to your dumb project using java"
That was pretty toxic for a kneejerk reaction.
Wow, the speakers point was so totally missed it was comical. That was just actually insulting and rude to the speaker in my opinion.
Yup, anyone defending this behavior needs a screw tightened.
The dev "pushing back" was being an asshole probably because of deep insecurity of gasp there being other programming languages than C.
Literally rust is currently being proposed for maybe new drivers and basically nothing else ATM. Nobody is suggesting rewriting code in rust or forcing people to learn rust. It is literally just "Hey, might be nice to write this driver for my mouse in a memory safe language".
I would assume this type of pushback is one of the main reasons a project like Linux is trustworthy in the first place.
That wasn't the nature of the pushback.
He did a presentation on making a fs in rust, the response from this dev was "we won't be converting to your religion. We are going to continue modifying c code and your dumb rust code will always be a second class citizen."
Literally just hostility for hostility sake. He wasn't proposing to rewrite everything in rust. He wasn't proposing that everyone learns rust. He was just giving a freaking presentation on making a rust fs that integrates with the kernel and was immediately trashed for spreading religion or whatever.
Non-technical nonsense is charitable.
What was literally said didn't include the words "always" or "your dumb rust code". From the subtitles with slight manual fixes:
> I suspect part of the problem here is you're trying to convince everyone to switch over to the religion as promulgated by rust and the reality is that ain't going to happen because we have 50 plus filesystems in Linux, they will not all be instantaneously converted over to rust. Before that happens we will continue to refactor code because we want to make the C code better. If it breaks rust bindings, at least for the foreseeable future the rust bindings are a second class citizen and those file systems that depend on the rust bindings will break and that is the rust bindings problem, not the file system community at large's problem and that's going to be true for a long long time, okay, and I think we just simply need to accept that
That seems rather technical to me. To put words into their mouth because they had a snarky tone, or claim the presenter was "immediately stacked for spreading religion or whatever" hardly is.
They literally said "spreading your religion" at the very start of their critique. I think I'm correctly reading the tone of the rest of the comment even if I didn't verbatim quote them.
From the closed captions with minor editing. In response to "we are going to provide API bindings"
> I suspect the problem here is you are trying to convert everyone to the religion as promulgated by rust and the reality is that ain't gonna happen. Because we have 50 plus filesystems in linux and they will not all be instantaneously converted over to rust. Before that happens we will continue to refactor code because we want to make C code better. If that breaks the rust bindings at least for the foreseeable future the rust bindings are a second class citizen. Those file systems that depend on the rust bindings will break and that is the rust bindings problem not the file system community at large problem. And that's going to be true for a long long time, OK. And I think we just simply accept that right because the answer you are not allowed to refactor C code because it would break 5 critical file systems that distros depend on is like not a star, OK.
> They literally said "spreading your religion" at the very start of their critique.
And that critique is near the end of all the people who asked questions or made comments. So no, the presenter wasn't "immediately stacked" when making that presentation.
> They literally said "spreading your religion" at the very start of their critique.
If you'll re-read the quote you claim to be literally quoting, nowhere does it say "spreading your religion":
> > I suspect the problem here is you are trying to convert everyone to the religion as promulgated by rust...
Potato pohtato
Keep that in mind someone literally misquotes what you "literally" said.
No, it says convert everyone to whatever religion is “promulgated by Rust”... which is a stronger accusation (spreading vs. converting everyone).
The actual quote was even worse.
Linus has the wisdom to see the writing on the wall - the kernel is becoming too complex to be maintained and extended by newcomers; the pool of C ninjas that can handle it reliably is diminishing. This kind of foresight is what makes Linux trustworthy in the first place. A lot of current individual contributors lack that vision and fail to understand the reason for introducing what they see as unneeded complexity.
The other reason Linux is trustworthy because of the technical meritocracy culture. But since Rust is not a technical choice, as Rust cannot per-se do things that are impossible in C - you can do anything in C - the introduction of Rust falls outside the parameters of the regular rough-but-mostly-fair Linux exchanges. This leading to toxic reactions from the less socially-abled.
> But since Rust is not a technical choice, as Rust cannot per-se do things that are impossible in C - you can do anything in C
Have anything in particular in mind? It's been my understanding that Rust actually can do everything C can, but the additional safety guarantees imposed by the type system make it a bit harder.
It's true that with a moderate dose of unsafe, and now that #asm!() is stabilized on major platforms, Rust should be able to go the same places as C.
Lots of that, which is why we are going to have memory error CVEs for the next hundred years.
https://news.ycombinator.com/item?id=41386939
A comment there has a link to a video of what seems to be the final straw.
Also linked in the email in the GP.
> Lastly, I'll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code.
That was painful to watch.
A redditor pointed out [0] that this is exactly what they would do to sink Rust adoption. Even if you agree with the substance of the argument, the delivery is rude and unhelpful. I hope this resignation is a wake-up call, and much of the onus is on C devs to be more collaborative.
0: https://www.reddit.com/r/linux/comments/1f3q0l8/one_of_the_r...
Why do C devs even have to be 'collaborative' about Rust modules? The latter would typically ingest C APIs, most likely via bindgen, making C code the "source of truth" about what the API is - because Rust modules are self-contained and C is the only stable ABI that Rust supports. All the type-checking smarts that the video talks about are purely on the Rust side. If a new 'raw' low-level C API is needed to build better smarts on the Rust side (which seems to be what's involved in some of the fs proposals) that can just be a self-contained proposal, with very lightweight changes on the C side of the code. This whole thing looks like a tempest in a teapot to me - and to be clear, this absolutely includes the Linux dev's complaints, which are extremely poor form.
Because they shouldn't be "C devs" but "kernel devs" with a common goal?
Because internally the kernel maintains API compatibility, so if some internal C API changes the change needs to update rest of C code consuming it
If kernel includes Rust, then that C code change could also require applying fixes to Rust code that breaks from that change
That burden would fall on Rust maintainers. If the Rust code goes unmaintained and nobody is around to pick it up, it just gets dropped from Linux releases that rely on the up-to-date C API.
The Rust maintainers said they would maintain the Rust bindings. But wouldn't it be nice to have a heads up that the bindings might break? Or whether assumptions have changed? Or even what the assumptions are?
It's a little tough to build a safe abstraction layer on top of C or encourage maintainers to stick around with a hostile "that's a _you_ problem" mentality or inaccurate rhetoric that Rust are trying to force their religion onto the C devs.
For those who don’t or can’t watch the video, or want to know who is saying what, here’s an LWN article describing what happens in that section of video.
https://lwn.net/Articles/978738/
While I disagree with his opinions here, Ted T'so is a long-time Linux kernel dev. He's been around since close to the beginning.
https://en.wikipedia.org/wiki/Theodore_Ts%27o
Unless the Linux developer community at large requested Rust in the kernel, this is good news.
Good news for whom? The mental safe space of old time kernel developers? Or good new for users who will continue to have to deal with kernel panics and other memory issues.
> users who will continue to have to deal with kernel panics and other memory issues.
I have not seen many of those in my close to 32 years of involvement with Linux. In the beginning of the project they did occur 'every now and then' but once Linux got past v1.2 or thereabouts they're about as rare as hen's teeth. If Rust ever becomes widespread enough for kernel developers to pick it up with ease it will be a welcome addition but until such a time I prefer for the project to remain C-focused so as not to close out a large fraction of the potential developer base. If that means that some 'competing' kernel gets written in Rust and takes over from Linux that'd be fine by me as well, may the best [1] kernel win.
[1] see https://en.wikipedia.org/wiki/Worse_is_better
I admit it's not often I see a direct panic. But I do see bugs caused by memory issues relatively often. In fact two weeks ago I made a patch for a memory issue in a wifi driver that caused it to drop connections. The long list of CVE is more direct proof though. By far most of them are memory safety issues.
Suggesting making a new kernel is just total FUD. This is a multi decade project. It's like saying to a person who want some legislation in their country to change "why not make your own country, may the best country win". It's just so far removed from reality I'm very surprised I have seen this argument more then once.
> Suggesting making a new kernel is just total FUD. This is a multi decade project.
Linux started as a hobby project of a single student and just a few years later it was already possible to build a full-blown UNIX desktop system with Linux as kernel.
Why should that not be possible to replicate today? Especially with modern development tooling and a big and motivated language community?
> Why should that not be possible to replicate today?
What is missing is the user base! When Linus started his project, many people knew Unix in their professional life and were disappointed with what the market (M$) was proposing for the personal computer world.
Today, no such multitude is waiting for the next Linux.
Linux may not be perfect, but it's definitely good enough.
Ideally such a Rust kernel project would implement a drop-in-replacement for the Linux kernel, so that Linux distros could select between the original Linux kernel and the Rust 'imposter'. That way the users would already be there. It would just be a detail like GNOME vs KDE, X11 vs Wayland, or glibc vs MUSL.
What was acceptable in 1995 is not what is acceptable today. Linux took literal decades + in the billions of dollars to build. It's ridiculous to suggest a rust project can just catch up to that with a few developers and no funding in any sane timespan. If you think it's reasonable to suggest "Just outcompete this heavily and continuously developed 34 year old project which has the backing of the largest technology firms on earth" I really don't know what to tell you. We live in different realities.
That doesn't even begin to touch on the problem that linux came at just the right time.
Sure it's foolish, but so was trying to 'outcompete' industry giants like IBM and Microsoft in the early 90s with a hobby kernel. That didn't stop a certain Finn from just writing a kernel anyway. If that project hadn't taken off, then maybe another one, or another one.
Replacing any substantial parts of the Linux project with Rust also would be multi-decade effort, most likely more effort than forking off a separate evolutionary branch (which is probably the most realistic option). Such forks happened all the time in the history of UNIX.
It was considerably less foolish then, then now. It's not even close. The complexity of the operating system kernels has more then increased 50x over the last 34 years. It's not even remotely comparable.
No one wants to replace substantial parts of the linux project with Rust. This is a straw man, and the same bad faith argument the set in their ways kernel greybeards are making. People just want to be able to write green field drivers in Rust.
> The mental safe space of old time kernel developers?
As long as they are the majority of the kernel developers, their wish is what matters the most.
Not users? Linux development is it's own reward?
Users should only need to care about what happens in user space. And the most important promise of Linux is "don't break user space". The kernel's programming language is literally just an internal implementation detail, irrelevant for Linux users.
Ah, I see the distinction. Thanks!
The security vulnerabilities that affect my PII kinda contradict the idea that the kernel is an implementation detail. It’s not an implementation detail if I do, in fact, have to care about it.
The wish of the lead developer is for Linux development to continue beyond the life of the current maintainers. Training to be a competent system programmer using C is unnecessary long and painful. There aren't enough C hackers coming up anymore. The Rust learning curve is a bit sharper than C for the first weeks but gets you to a competent and non-dangerous state much more quickly after that.
This problem is not expected to be solved by current maintainers. They're just asked to make room for the next generation. "It should hurt you like it hurt me" is not an acceptable response.
I don't understand this argument...C is a very simple language. Does the proverbial rust programmer who doesn't know C even exist?
A musket is a very simple weapon! Does the proverbial SCAR mk20 gunslinger who doesn't know about muskets even exist?
If C is actually "very simple", you should be able to write a working interpreter for C in a short time, say, one week. (I would assume that you know how to write an interpreter in general, of course.) Can you?
> Does the proverbial rust programmer who doesn't know C even exist?
I have seen enough Python or JS programmers learning Rust without having any working knowledge about C. Of course Rust is not an easy language to learn for them, as they have to deal with a concept of explicit memory and lifetime that have no equivalent in Python or JS, but otherwise I didn't see any complication specific to Rust.
It is never good news that "nontechnical nonsense" causes a major maintainer to step down, regardless of Rust or not-Rust.
What was heard in the video was both technical and sensible.
The argument was "I don't want to learn Rust, I'm not going to learn Rust, and if you put a non-C language in the codebase, I'm going to break it without giving a shit". Not sensible in the least.
I heard more like: "We have been borking like this for 26 years now and the result is amazing. If you want to introduce a new API for a couple of eventual use cases, you are welcome to do so, but don't event think to impose any additional burden on us."
Did we see the same video ?
The rust guys were just asking for semantic information about the current C apis so they could try to encode them into the type system.
All they got in response to that were made up problems of them supposedly forcing everyone to adopt their religion, rust being too OOP or other nitpicks that had nothing to do with the issue the presenters were trying to talk about.
Nobody even answered their questions, people which obviously didn't even look at rust for more than an hour gave their opinion on why what they're doing is bad and destined to fail. It was rude, tone-deaf and not a single technically sound argument was actually made.
I love linux and I'm fine with the maintainers deciding to use C if they want to, but the behavior by the old guard here was actually appalling and reeks of deep insecurity and inability to communicate.
> people which obviously didn't even look at rust
Since when is Rust a requirement to help Linux development? Only an utter idiot could think that such a big and successfully community would put any effort in addressing any issue that is not posed in their natural language!
If you want to introduce Rust into Linux, you learn C, you learn Linux, you add and maintain whatever you want.
> Since when is Rust a requirement to help Linux development?
It's not and it shouldn't be, but it is most definitely required if you want to criticize it's integration into the kernel due to its supposed flaws/merits in a "technical" discussion.
Nobody is forcing anyone to learn rust, the RiL folks are fine with maintaining bindings and handling the fallout of C API changes. They didn't even get to say that, because they were shouted at for asking a question.
> If you want to introduce Rust into Linux, you learn C, you learn Linux, you add and maintain whatever you want.
Which is basically exactly what the RiL community is doing. In the posted video you can see them TRYING their best to learn about the undocumented invariants of a C API and getting nothing but flak for it for completely made up reasons. I might be hard to understand, but many of the strongest advocates of rust know C well and are opposed to using it themselves for good reasons. The folks maintaining C API don't have to care much about the rust part, except maybe giving a friendly heads-up when they change API's they depend on, like you would in any kernel development work where you are impacting another subsystem.
Apparently this is too much to ask from some of these C grandpas.
While these guys have undoubtedly made great contributions to Linux and FOSS and I'll be forever thankful for that, some of their behavior towards the RiL community has been appalling and petty. They have been resistant to any sort of change, even if it does not impact them at all, are quick to criticize without any attempt at understanding the efforts and benefits of Rust integration or even making any technically coherent argument. Constructive criticism and open discussion is important, but it should be based on accurate information and a willingness to learn instead of knee-jerk reactions and reacting to people wanting to learn about the API of your subsystem with outright and unwarranted hostility.
He talks of a new memory safe kernel disrupting Linux the way Linux disrupted others.
Well, maybe that's exactly what should happen. Maybe rust should have never been allowed in the kernel in the first place.
It's caused a lot of trouble so far and for what? The dev community is fractured and infighting is rampant.
> It's caused a lot of trouble so far and for what?
The "for what" seems pretty obvious, no? It's the same reason you would use Rust over C in any other project. Memory safety and more modern PL features.
In my opinion, in the case of the Linux kernel, Zig (once it reaches 1.0) would be a much better, more natural, and less painful choice than Rust.
Lets hope that zig becomes a memory-safe language before 1.0 then.
Like stated, zig isn’t stable yet. And in general the kit isn’t on a good level yet to replace C in Linux.
And, there’s still no good and fast allocator:
https://github.com/ziglang/zig/issues/12484
Kernel code shouldn't need a 'good and fast' allocator though, since preferably it shouldn't heap-allocate in the first place, or at least not frequent enough that allocator performance matters.
You’re correct - was just something which is stopping people to try the language. And with that you implicate less users, less matured toolkit etc.
Is there even a plan to make zig memory safe?
As someone who's tried zig and who enjoys c. I highly doubt it would be any more acceptable for people dedicated to working on c than rust or c++ is.
> Well, maybe that's exactly what should happen. Maybe rust should have never been allowed in the kernel in the first place.
Can you clarify these two sentences? You say there should be a memory-safe kernel, and then you say Rust should never have been allowed, which is the opposite.
That memory safe kernel doesn't necessarily have to be Linux itself.
Same opinion here, have all this giant proRust energy and put it behind a few Rust kernels, combining the Rust super powers with latest kernels architectures and have at least one Rust kernel that is not UNIX but something super modern.
There is Redox but adoption and traction is minimal. But these things take time so maybe it will become popular in the future.
I would have expected more then one Rust kernels. It kind of seems that Rust community is missing the ability or the desire to implement a kernel and would like the Linux kernel devs to do the work for them.
There are tons of embedded kernels, Android uses Rust in their Linux, Windows already ships Rust in their kernel. Just because someone mentions one project doesn’t mean it’s an exhaustive list.
I mean notable projects, I do not consider toy projects in this.
Just because someone pushed some Rust into a kernel it does not make that kernel a Rust kernel, this is the issue with Rust community , hyping the fact that some devs managed to pushed a few lines of Rust in some kernel as some big victory.
Even Mozilla gave up on making a browser in 100% Rust, it seems that rewriting in Rust is not that easy and people like to talk then do the work.
I'm not talking about toy projects. I'm talking about real, used in production kernels. One of those embedded ones is used by my employer, for example.
> people like to talk then do the work.
There are tens of millions (I'm being conservative here, not sure I'd claim 100M) of Rust code running in production, at many very large tech companies. I feel like you have an opinion and are trying to fit the facts to it, rather than the other way around.
So why are you naming that non toy kernel your company uses in many devices in production?
I did not say that there are not tons of millions of Rust lines of code used in production, I wish there would be a modern kernel for PCs not some micro/nano kernel for some board. I see it a big waste to push Rust into Linux or Windows kernels instead of those competent developers writing that new modern kernel, it feels like they are forced to work on Linux/Windows so they want to have fun with Rust at work. If Rust is so superior then you just need to start the kernel, prove is super fast and super safe and Big Tech will put the money so they can use it on their servers, Like why would Netflix not use the super kernel written in Rust ?
Ours is https://hubris.oxide.computer/, used for various parts of our product, namely the root of trust and service processor.
Other examples: https://tockos.org/ & https://oxidos.io/
"just" writing a production-grade Linux equivalent would take decades. Some people are working on such projects, but those will take a long time, if ever, to mature, whereas improving Linux means making positive change today. Both things can be pursued in parallel, by different people. It's not an either/or.
Good luck to this new kernels, my guess is that you do not get any speed boost from using Rust, sure you might get fewer bugs but since we do not have a basic kernel and OS yet with a GUI that I can run at least in a VM tells me that something is not matching the hype, maybe the constant fighting with the type system make adding new things or updating existing code super slow.
I honestly wish to see modern OS as a competition to the decades old Linux and Windows.
It might seem like that if your only exposure to Rust is the comment you replied to.
https://github.com/flosse/rust-os-comparison
> He talks of a new memory safe kernel disrupting Linux the way Linux disrupted others.
So the next paragraph means:
> Maybe rust should have never been allowed in the [Linux] kernel in the first place.
What they're getting at is that it probably would have been better if the Rust people had started their own kernel project, cherry-picked the pieces of Linux they wanted, and then made their own new thing without three decades of obsolete Unix/Linux baggage. This would mean they could spend their time actually writing software and and less time trying to convince a bunch of C programmers that their time is at an end and their influence is counterproductive.
Describing it as “the Rust people” as though they are separate from the a Linux project is a rhetorical sleight of hand to imply some sort of outside invasion.
These are a Linux kernel people who want to use Rust. Writing a new kernel would be fundamentally different than working on Linux.
Also, they are “writing software,” and have been for a long time now. This isn’t just some random arguing on mailing lists, this is actual patches, with folks like Asahi and Android writing real meaningful drivers on top of it.
They are separate from the other kernel developers, but not in the negative way you seem to want to assign to me. They aren't an outside invasion, they are a cultural revolution.
They may want to work on Linux but it's clear that the rest of the Linux developer community does not want to allow it, for reasons you are free to interpret as positive or negative as you see fit.
They want to write software, and they are getting somewhere, but they are restricted by the attitudes of the rest of the Linux kernel people fighting against them, so they are sucked into constant flamewars and divisive infighting. All just so they can say what they are working on is "Linux".
At the end, the question must be asked whether or not Linux and its decades of Linux/Unix baggage are worth holding back the progress represented by a kernel that is Rust from top to bottom, and written with safety and security as its top priorities from day zero instead of decades after.
TockOS, Redox, Hubris,...
Window GDI regions, CoreWrite, Drivers SDK
Android
Copilot+ PC firmware
> "the Rust people"
There is no such thing.
There are people developing a complete OS in Rust: https://github.com/flosse/rust-os-comparison
There are people interested in making the Linux kernel more memory safe using Rust. And from what I am observing they aren't interested in a hard fork and are looking for collaboration.
These are different populations.
Contrary to what Theodore Ts'o is ignorantly saying, Rust is not a religion.
Meaning: Maybe there should be a competitor to Linux written in Rust
BTW: There are a few Rust OS kernels, but none of those have the popularity of Linux of course.
Like something for mobile phones using Rust alongside a managed runtime?
Would be interesting, maybe name it after a color...
Can't find the name of that now. But there's also RedoxOS and probably several more.
He's talking about Android, not Fuchsia.
Indeed.