Linux people doing Linux things, it seems.
Here’s the thing: you’re not going to force all of us to learn Rust.
That’s precious coming from Linux developers.
I am a heavy Linux user. I run multiple microservices on multiple headless devices all Linux.
This sounds like every fucking Windows user you’ll ever encounter.
“Here’s the thing: you’re not going to force all of us to learn to use Linux.”
So, yeah…
It’s just their ego showing through.
It basically now comes down to the current devs depending on new Rust devs for anything that interacts with Rust code.
They could just work together with Rust devs to solve any issues (API for example).
But their ego doesn’t allow for it. They want to do everything by themselves because that’s how it always was (up until now).
Sure, you could say it’s more efficient to work on things alone for some people, and I’d agree here, but realistically that’s not going to matter because the most interactivity that exists (at the moment) between Rust and C in Linux is… the API. Something that they touch up on once in a while. Once it’s solid enough, they don’t have to touch it anymore at all.
This is a completely new challenge that the Linux devs are facing now after a new language has been introduced. It was tried before, but now it’s been approved. The only person they should be mad at is Linus, not the Rust devs.
I finally watched the talk today and that wasn’t what I thought he meant. What I thought he was getting at was that the rust parts of the kernel interact with lots of other modules written by people who don’t know rust. When those C modules change their semantics in ways that break the rust code, they can’t go fix it because they don’t know rust. In fact, whenever they make a change, they don’t even know if they broke some rust module, because they don’t understand the rust code well enough. And this is something that everyone is going to have to live with for the foreseeable future, because you can’t force all those other kernel hackers to learn rust.
If you are that good in C(pp), I guess understanding rust code of a module is not sooo hard… I mean, I learned what I know about C from reading stuff in the Kernel that made my embedded Linux project not working.
But I have yet to read rust.
It’s a whole different ballgame. I’ve written a good amount of C and C++ in my day. I’ve been learning Rust for a year or so now. Switching between allocating your own memory and managing it, and the concept of “Ownership” https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html is just something many devs set in their ways aren’t willing to do.
I understand where they’re coming from, I’ve gone through massive refactors with new tech in my career. I think this approach needs to be more methodical and cautious than it is, but I don’t think they are correct in the end result. I think a memory-safe language is the way to go, and it needs to happen.
This to me is a classic software project with no manager and a bunch of devs arguing internally with no clear external goals. There needs to be definitive goals set over a timeline. If someone doesn’t agree after a consensus is reached they can leave the project. But as of now I think as others have said this is 80% infighting, 20% actual work that’s happening.
Switching everything from C to Rust because it has better memory safety is more akin to changing languages from English to Esperanto because it has gender neutral pronouns and other cool features. Maybe it’s a good idea, but it’s understandable that some people are reluctant.
Maybe it’s a good idea, but it’s understandable that some people are reluctant.
I understand that position. I also understand how the words and phrases that the C community has used to communicate with the Rust community seems to be completely dismissive, not just reluctant.
I quoted what I did explicitly because of how a statement like that comes off to the person it’s aimed at. It doesn’t make them feel like they’re on an even footing working on the same project with the overall goal of it becoming better.
memory safety is more akin to changing languages from English to Esperanto because it has gender neutral pronouns.
I mean… not at all? Memory safety is huge for cybersecurity, buffer overflows and the like are common attack surfaces. C requires you to have deep knowledge of safe memory management practices and even then you can end up with memory issues. Rust was developed to avoid such issues entirely. I understand the reluctance but it feels to me like arguing “we should just stick with COBOL because it works.”
Gender neutral pronouns are pretty huge too. Sure you can do them in English without too many problems usually, just as it’s also possible to code safely in C. It requires everyone to change their old habits, but it’s much less of a change than is involved in adopting a whole new language.
Anyway, I do like Rust better personally.
People prefer what’s familiar to them. Rust is completely foreign to them, the syntax is very different, the community is different (and often much younger), it still has many issues and is not ubiquitous, and many people are just slow/averse to change in general. So I absolutely understand the hesitation. And some just don’t like it for other reasons like the syntax, learning curve or other reasons. There’s also still a host of memory-related things Rust doesn’t fix like stack overflows, leaks, bitflips, unsafe context code, and just bad coding practices in general.
I understand the reluctance but it feels to me like arguing “we should just stick with COBOL because it works.”
For those depending on COBOL code that does the job and has been doing it just well for a few decades, there are approximately zero good reasons to not stick with it.
Vast majority of the cybersecurity community: “an absolute ton of exploits come from memory safety issues with C/C++, we should move to memory safe languages like Rust to greatly reduce security risk and make everyone safer”
You: “Ehh Rust has a couple features, but it’s totally not worth switching from my precious precious C”
like Rust
But no one is talking about that that is doesn’t need to be Rust. There are alternatives that can do as much if not more with the type system & safety while being as low-level as C without some of Rust’s restrictions.
Turns out there is a name for that. I had to look it up. Never seen such a striking example before.
I don’t think it does? https://en.wikipedia.org/wiki/Gender_reform_in_Esperanto
“It’s herding cats: introducing Rust effectively is one part coding work and ninety-nine parts political work…”
All software development in a team is. More like 20/80 or 40/60 if you’re lucky.
Except in this case, it was a bunch of old C devs who aren’t just resistant but openly hostile to change, and they’d rather bully people into silence than try to progress.
If I go to any of the teams I interact with who program their components in C++ and proposed Rust or anything else, I’d get a similar reaction. They’re very good at C++ and they very rarely have memory and threading issues. 😂
They very rarely have memory and threading issues
It’s always the “rarely” that gets you. A program that doesn’t crash is awesome, a program that crashes consistently is easy to debug (and most likely would be caught during development anyway), but a program that crashes only once a week? Wooo boy.
People vastly underestimate the value Rust brings by ensuring the same class of bugs will never happen.
They don’t get, that without memory issue resistant language, not a lot of new blood will be as good as them dealing with that stuff since they already have that solved in the language itself.
It is about making kernel development future proof, so that new devs keep on coming and don’t create massive security holes on the way.
Well this is how I understand it.
Several downvotes with zero comments to refute or discuss your point. Some devs don’t like you calling them out
I mean, it is. RedoxOS is just that. But it’s not Linux and that means a lot of things.
Ironically the majority of the rust memory management ruleset is called ownership, and they are unwilling to release any of it, and claiming all of it, so there’s an out of memory error.
I didn’t understood your criticism, what are they unwilling to release? What are they claiming all of? Why would ownership rules cause an OOM?
Sharing stack memory is a bad practice in C as well btw.
If you want to talk about bullying you ought to include all the rust zealots who show up to shit on C every chance they get.
bunch of old C devs
I knew this ageist bullshit would pop up. I know we lost our mentors and are kinda feeling in the dark, but the moment people pop out the ageist slurs I know they’ve got nothing to say.
The C developers are the ones with the ageist mindset.
The Rust developers certainly are not the ones raising the point “C has always worked, so why should we use another language?” which ignores the objective advantages of Rust and is solely leaning on C being the older language.
Here’s what I think. Both opinions are correct.
Rust is sufficiently different that you cannot expect C developers to learn rust to the level they have mastered C in order to be working at the kernel level. It’s not going to happen.
I don’t really know too much about rust. Maybe one day I’ll actually mess around with it. But the one time I looked at a rust git repo I couldn’t even find where the code to do a thing was. It’s just different enough to be problematic that way.
So I think probably, the best way IS to go the way linus did. Just go ahead and write a very basic working kernel in rust. If the project is popular it will gain momentum.
Trying to slowly adapt parts of the kernel to rust and then complain when long term C developers don’t want to learn a new language in order to help isn’t going to make many friends on that team.
But that’s the thing where you are wrong. They clearly state they don’t want C developers to learn Rust. In the particular video posted he was saying “I want you to explain to me how this particular API works so that I can do it”
The concerns about who fixes what on a merge when the C code breaks Rust code are valid, but that’s easily fixed by gathering with the Rust developers, explaining the changes and letting them fix it.
You could alternatively phrase “But that’s the thing where you are wrong” as “But here’s the crux of why I disagree”, it’s a bit more personable
This isn’t a disagreement. One person is stating something incorrect. You can disagree on opinion, but facts are facts. The person being referred to here isn’t asking others to learn Rust, they are just asking for more information about the already existing C code so that they can write their Rust code to interoperate with it. This misunderstanding is exactly why that developer was getting heckled on stage, and is the reason why now one has left the project. I would appreciate it if you didn’t make a misunderstanding sound like a valid opinion. Enough damage has already been done.
I’ve inserted myself into your C project because only idiots write C. Rust is the one true god, mUh MeMoRy sAfteY! Now please explain to me how C works.
LMAO
Now please explain to me how C works.
That’s not what they’re asking. It’s not about how C works, it’s about how specific APIs written in C work, which is hard to figure out on your own for anyone who is not familiar with that specific code. You’ll have to explain that to any developer coming new into the project expected to work with those APIs, no matter their experience with C.
But the one time I looked at a rust git repo I couldn’t even find where the code to do a thing was.
IMO that tells more about how the project was organized and names things than the language used.
So I think probably, the best way IS to go the way linus did. Just go ahead and write a very basic working kernel in rust. If the project is popular it will gain momentum.
As the other commenter pointed out, there’s Redox. The issue is that this completly disregards an incremental approach: you have to rewrite everything before it comes usable, you can’t do it piece by piece. Currently the approach of Rust for Linux is not even to rewrite things, but to allow writing new drivers in Rust.
Trying to slowly adapt parts of the kernel to rust and then complain when long term C developers don’t want to learn a new language in order to help isn’t going to make many friends on that team.
Have you seen the conference video? That’s not just refusal to learn a new language, it’s open hostility. And it’s not the only instance, for example Asahi Lina also reported unreasonable behaviour by some maintainers just because she wrote Rust code, even when Rust was not involved.
I think the point of redox is more than just rewriting Linux in Rust. Architecturally they are very different. Redox uses the more modern microkernel approach, whereas Linux is a modular monolith. There are advantages and disadvantages to both designs. They are actually polar opposites in fact. The compromise is something called a hybrid kernel which is used by Windows NT.
This is true, but the differences go even further than that. Redox is intentionally non-posix-compliant. This means that userspace programs written for posix operating systems may or may not need patching to even compile.
Part of the philosophy of Redox is to follow the beaten path mostly, but not be afraid of exploring better ideas when appropriate.
RedoxOS! There’s been solid progress too, beyond just having a functional microkernel, they have many of the userspace tools/their version of coreutils, even a desktop environment already mostly implemented!
My understanding is that it shouldn’t be too bad to port some other things over as well. The main issue I had was just the lack of drivers, especially since it’s still tricky even on Linux, and the microkernel architecture (though more secure) also means there’s no way to reuse any of those from Linux
Same with Ironclad kernel and OS written in Ada Programing language. Nice to see these systems development
I think this overall is a better idea. I’m going to say this because, I thought I’d look into rust today. So I installed it, setup vscode to work with it etc. And it’s all up and running. I thought I would port over a “fairly simple” C# project I wrote recently as a bit of a test.
While I’ve generally had success (albeit with 30+ tabs open to solve questions I had about how to do certain things, and only making it about 20% into the task) I’m going to say that it’s different enough from C, C++ and C# (all of which I can work with) that I really don’t think it is fair to expect C developers that have day jobs and work on the kernel in their spare time to learn this. It’s fundamentally different in my opinion.
Now, I don’t condone any bad attitude and pushing away of rust developers from the project. But there’s no way they’re going to want to do anything to help which involves learning a new language. It’s just not going to happen.
Likewise, C is not a language most new developers are learning. So, I feel like over time there won’t be so much of an influx of new kernel developers and any Rust based kernel could find itself with more contributors over time and taking over as the de-facto kernel.
In terms of Redox (not looked into it yet). So long as there’s a different team working on the userspace tools. I would say the main task should be getting a solid kernel with drivers for most popular hardware etc in place. The existing GNU tools will do until there’s a kernel that is able to compete with the C one. But that’s just my opinion.
Good news there’s a project that aims to implement Unix in Rust called Redox and it’s already a good enough project for studying microkernel design
Yeah, the Rust guys’ proposition is roughly this:
Hey you guys with 20-30 years of experience doing a single thing very well. Let’s nullify most of that skillset and replace it with a thing we’re good at.
Don’t worry, we will teach you.
They’re not technically wrong about Rust being a better choice for a kernel, of course. They’re just incredibly misinformed about the social hurdles they need to climb over for it to happen.
Honestly, if anyone has become a master in C, they can become a rust master in short order. It’s different, but not THAT different. The roots are the same.
I don’t know. Rust seems like a better C++ to me rather than a better C. Plain C is a very simple language.
Just go ahead and write a very basic working kernel in rust.
I don’t get this stance, really. If I want to write a driver in Rust I should start by creating a completely new Kernel and see if it gains momentum? The idea of allowing Rust in kernel drivers is to attract new blood to the project, not to intentionally divert it to a dummy project.
Rust is sufficiently different that you cannot expect C developers to learn rust to the level they have mastered C
If you watch the video, no one asked anything from the C developers other than documentation. They just want to know how to correctly make the Rust bindings.
Note that Rust is not replacing C code in the Kernel, just an added option to writing drivers.
That’s why I often recommend D instead.
Has a much more C-style syntax, except much more refined from the years of hindsight. The catch? No corporate backing, didn’t jump on the “immutable by default” trend when functional programming evangelists said for loops are a bad practice and instead we should just write recursive functions as a workaround, memory safety is opt-in (although “safe by default” can be done by starting your files with @safe:), some of the lead devs are “naive centrists” who want to “give everyone a chance at coding even if they’re bad people (nazis)”, implementing new changes to the lang has slowed down significantly up until the departure of Adam D Ruppe and the drama surrounding it, etc.
“safe by default” can be done by starting your files with
@safe:
Last time I heard about that it was much more limited than Rust, for example it even disallowed taking references to local variables. Has something changed since then?
D has many memory safety features. For local variables, one should use pointers, otherwise ref does references that are guaranteed to be valid to their lifetime, and thus have said limitations.
part of the problem is that old-time kernel developers are used to C and don’t know Rust," Torvalds said. “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.”
Linus hit the nail on the head. If you’ve been a Kernel dev for a decade or more, and have spent decades learning the ins and outs of C, why would you want to switch to something that is similar, but different in a lot of ways, just because a small subset of devs think it’s the best way forward? Let them handle Rust and the majority of devs will keep using C, even though Rust is objectively better.
As one of the other quotes suggested: fork the kernel project and rewrite it entirely in Rust, that way there isn’t any push back from the C devs. Replacing C with Rust in the upstream kernel is akin to replacing the engine in a car while it’s running or being used every day.
This specific talk was about defining shared common interfaces so these different groups could work together and the guy who actually talked him into stepping down essentially said “I’m gonna keep writing C and if that breaks your rust stuff that’s not my problem”. This isn’t about convincing the c devs to write rust it’s about convincing them to work together when some of them seem to have made up their mind to sabotage rust support (either through indifference or willful interface regressions). Personally I’m more ashamed what this points to for someone new wanting to come in contribute to Linux.
Ah, but I still agree with the C devs, it creates unnecessary headaches for them. Also, old habits die hard.
I view it as the same way ZFS is supported: Linus and Greg KH are like “you can maintain it, but we don’t give a shit about it, and if what we do breaks ZFS support, well too bad.”
The reverse is also true. Any dev wanting to contribute to Linux in rust which linus himself allowed (despite his silence on this matter) are just going to have to deal with constant headache trying to maintain compatibility with the C interfaces which the devs keep breaking. Either they should’ve never allowed rust in the kernel or they should force devs to at least act in good faith and collaborate (and any that refuse to, well they should be ousted because they can’t behave responsibly). This entire situation is so toxic and I see that as a failure in leadership. That zfs comment is also a little toxic but I don’t think it’s a direct quote. It also doesn’t seem like a fair comparison because from what I can tell zfs isn’t even part of the kernel code base and due to legal reasons cannot be. While it would be great for the kernel not to break it, it is, for all intents and purposes an external project. This rust debacle is different because it’s rust kernel devs and c kernel devs both operating in the same project and trying to find some kind of alignment. To me it seems like there’s enough of an acknowledgment of the value of memory safety that rust support was considered but there’s no authority figure actually supporting it or defending the devs that were invited to actually contribute in it. What a mess.
I think all the Rust devs should remove their code and leave. And when in the future the Linux devs change their tune and ask for their help, they should refuse.
As one of the other quotes suggested: fork the kernel project and rewrite it entirely in Rust
That’s not practically possible given the scale of the kernel. And doing a total rewrite is almost always a recipe for getting stuck and, if you ever create anything, creating something worse.
Replacing C with Rust in the upstream kernel is akin to replacing the engine in a car while it’s running or being used every day.
Almost all real-world software development is like this. That’s what we do.
Yeah it is a monumental task, but it’s also the one with the least push back. I don’t mean start from scratch, but convert the C code to Rust in a dev branch or something and release a Linux-Rust kernel image.
Almost all real-world software development is like this. That’s what we do.
I’m aware, I’ve written my own software even though I’m a SysEng, all I’m saying is that it’s not an easy process with a potential for disaster. Just look at CrowdStrike (not saying that they were attempting to switch languages but just the scale of the fuck up and the fallout that it caused), we don’t want that to happen with Linux.
The kernel is probably too large to rewrite the whole thing at once. This could lead to a future without any new C kernel devs, leading to stagnation, while the Rust kernel could be many years away from being finished. (Assuming we actually move away from C.)
At that point you might as well just start an entirely new kernel and hope it is good enough to eventually replace the Linux one once all devs are gone. Kinda the X11 and wayland thing.
the Rust kernel could be many years away from being finished.
the number I saw floating around was 3 years to production useful. regardless, C’s end days as the go-to, large systems level language are drawing nigh.
edit: tear
I think this number is overblown. Production useful doesn’t have to mean 1:1.
Running it without all graphics drivers would be fine for server use. Also, not all filesystems need to be ported: basic ones should be enough for start. But not only servers, home routers run Linux kernel…
If every OEM starts contributing their drivers in rust, this could move quickly…
I agree. C isn’t going anywhere anytime soon, but if we don’t start modernizing the kernel now we could end up with a future like the US government is in where all critical systems run on COBOL code and no one wants to touch it for the fear of breaking everything.
I’m not sure if it was in my above post or not, but the article said we should start modernizing the kernel now before someone does to Linux what Linux did to Unix.
Redox OS already exists and is functional (meaning it boots and has a GUI, but it’s lacking in various aspects), from what I understand it’s pretty much Linux/Unix rewritten entirely in Rust and looks pretty promising. In 5 or so years it could be a competitor with BSD and then overtake Linux once it has a proven track record.
It blows my mind that Linus is just so darn based all the time. That guy has a good take on like every issue.
Strong opinions. Sometimes Linus’s takes are ‘bangers’ &, while probably fewer, he’s had a lot ‘woofs’ on the opposite end.
Replacing C with Rust in the upstream kernel is akin to replacing the engine in a car while it’s running or being used every day.
That’s in no way what’s been proposed. Rust is used in a very well defined niche, nobody wants to get rid of C.
But it’s just that sentiment that got us here, you’re arguing against a non-existent threat, and thus reject the whole proposal.
I’m not rejecting it, I’m just saying that it’s very difficult to completely change the code of a critical piece of software. The long-term goal is for Rust to overtake C in the kernel (from what I understand, I’m a System Engineer, not a software dev. I know Go, not Rust) due it being memory-safe and about 30 years newer. Critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit (and get bitched out by Linus 😂) so I’m sure there is tons of code from the early 90s that could be made better with a newer language like Rust, but it’s not as mature as C right now so that’s not going to happen for a while, if at all.
The long-term goal is for Rust to overtake C in the kernel (from what I understand
Your understanding wrong. Rust is limited to some very specific niches within the kernel and will likely not spread out anytime soon.
critical code gets left untouched (a lot of the time) because no one wants to be the one that breaks shit
The entire kernel is “critical”. The entire kernel runs - kind of by definition - in kernel space. Every bug there has the potential for privilege escalation or faults - theoretically even hardware damage. So following your advice, nobody should every touch the kernel at all.
even though Rust is objectively better.
In some of its characteristics, Rust is certainly a good language. The borrow checker, however, still haunts my restless dreams today.
I’m a C/C++ dude but I heard it being called the “Karen compiler”. It doesn’t look that scary based on samples I’ve seen, but there’s way more to it I am assuming.
“Karen compiler” is almost perfect, except unlike Karens, the compiler is delightfully helpful with the error messages it gives you (usually). It usually gives a straightforward error, an error code, and sometimes, an easy fix.
As someone that started with Rust, but just yesterday had to fix some C++ code, working with any other compiled language makes me shudder. I have nothing but respect for devs that have to wade through stuff like that.
“If it ain’t broke, don’t fix it!”
I’m not a software dev, but I’d imagine that the codebase could definitely be reduced once most things are converted to Rust. From what I’ve heard, the kernel is a huge mess of spaghetti code that most people don’t want to touch, for the fear of going insane in the process 😂
One detail about Rust in the kernel that often gets overlooked: the Linux kernel supports arches to which Rust has never been ported. Most of these are marginal (hppa, alpha, m68k—itanium was also on this list), but there are people out there who still use them and may be concerned about their future. As long as Rust remains in device drivers only this isn’t a major issue, but if it penetrates further into the kernel, these arches will have to be desupported.
(Gentoo has a special profile “feature” called “wd40” for these arches, which is how I was aware of their lack of Rust support. It’s interesting to look at the number and types of packages it masks. Lotta python there, and it looks like gnome is effectively a no-go.)
It seems like gcc rust would pretty much fix that issue, since soon gcc will be able to compile rust for any architecture gcc supports.
Or wait for rust to support the extra languages. With LLVM adding new architectures or projects like gccrs. But all of these options are a way out and rust will remain device driver only for a long time I suspect - it is still experimental after all. I would hope that as rust in the kernel matures so do the available architectures that rust supports.
