Greg KH: But for new code / drivers, writing them in Rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this?

[-]

sheeproomer@reddit

Use Ada instead of your baby language of Rust, if we are at it now.

Tust invites only lazy development.

[-]

If Ada developers had stepped up and proposed it, and actually put in time to show its possible and desirable like the Rust ones did, are, and will do, perhaps that might have happened. But they didn’t.

[-]

cr8tivspace@reddit

But what will do with all our time if there is no bugs? How will we show off that we can build our lLinux five times because we have recompile?

[-]

Xatraxalian@reddit

Some good quotes in here.

(PS: Not a kernel developer)

I like Rust for my personal projects because it makes writing software MUCH easier compared to C, because the compiler can help you literally everywhere. I'm almost never bothered by the borrowchecker, but when it DOES pop up, I made a mistake somewhere or overlooked something... had I been programming in C, that would have been a point of failure.

And, it happens to EVERYONE; me in my personal projects or at work, but also the best kernel developers in the world.

Nobody is advocating to rewrite the entire kernel in Rust in one go, but if you can start writing NEW drivers in Rust, then replace older drivers with newer versions in Rust (i.e., as soon as something must be rewritten for whatever reason, THEN do it in Rust), then some new kernel functions could also be written in Rust. The Linux kernel could transition to Rust like that, for much safer programming. Granted, it'd probably take 10 or even 15 years, but good software projects aren't replaced or rewritten, they just slowly transition to something better over time.

[-]

Dejhavi@reddit

Nobody is advocating to rewrite the entire kernel in Rust in one go, but if you can start writing NEW drivers in Rust, then replace older drivers with newer versions in Rust (i.e., as soon as something must be rewritten for whatever reason, THEN do it in Rust), then some new kernel functions could also be written in Rust.

That's the funny thing,nobody wants to rewrite the kernel,they only want "facilities" to be able to interact with it

The Linux kernel could transition to Rust like that, for much safer programming. Granted, it'd probably take 10 or even 15 years, but good software projects aren't replaced or rewritten, they just slowly transition to something better over time.

Google (and Android) is already doing it:

[-]

Chippiewall@reddit

That's the funny thing,nobody wants to rewrite the kernel,they only want "facilities" to be able to interact with it

Nobody wants to do it right now because everyone thinks that driver development is a good low hanging fruit for a Rust experiment.

I think there's a fair few people in the R4L project (and others seemingly like Linus and Greg) who are interested in the idea of potentially expanding Rust into other parts of the kernel if it proves successful long-term.

[-]

round-earth-theory@reddit

The Rust team absolutely wants to actually start writing the kernel in Rust but they have to start somewhere and this somewhere is a good start. Once they have this process working smoothly, then I could see Linus making it the main branch so the Rust team can start actually writing parts of the kernel in Rust. And in the far flung future, Rust will start to overtake C until it's one day the dominant language. I'm not sure C will ever be really done, but I do see it getting boxed in more and more.

[-]

cloggedsink941@reddit

Once it gets a compiler that supports more than 3 architectures and stops being incompatible with itself every couple of years you mean?

[-]

CrazyKilla15@reddit

Thats the rust compiler since 1.0.

[-]

cloggedsink941@reddit

Ah I see you don't know what you're talking about. Please read up a bit about llvm and gcc and come back.

[-]

CrazyKilla15@reddit

LLVM famously changes/breaks its API pretty much every version. LLVM also supports more than 3 architectures, and thus Rust, which supports LLVM as a backend, does too.

Rust also more recently gained support for GCC as a backend, albeit still WIP, and thus supports architectures only GCC does as well. https://lore.kernel.org/rust-for-linux/CANiq72m+r1BZVdVHn2k8XeU37ZeY6VT2S9KswMuFA=ZO3e4uvQ@mail.gmail.com/

The GCC backend built and booted a Linux kernel with Rust enabled a couple years ago. Still, it is a work in progress.

You would know this if you werent a troll and actually knew literally anything about what you were talking about.

[-]

cloggedsink941@reddit

Rust also more recently gained support for GCC as a backend

No it hasn't. It has no validator and doesn't support all of the architectures.

[-]

steveklabnik1@reddit

It has no validator and doesn't support all of the architectures.

You're talking about gcc-rs, and /u/CrazyKilla15 is talking about rustc_codegen_gcc. Two different things.

[-]

Xatraxalian@reddit

I still think it is somewhat funny that Google is pushing Rust left and right even though they have Go. Then again, granted, Go is not a systems programming language. (At least, not in my opinion. One can use it for that purpose, but it's not best suited because of the garbage collector. And it still contains null / nil....)

[-]

bik1230@reddit

Google is mostly a C++ shop. Even now, years after Go was introduced, there are way, way more Googlers who write C++ than who write Go. And those C++ devs are learning Rust and starting to write new code in it. I wouldn't be surprised if in the next 10 years, Google has more Rust devs than Go devs.

[-]

syklemil@reddit

eagerly awaiting the arrival of a gcloud api library for Rust. I think they have a repo for it now at the very least.

on the kubernetes side it seems there's a trickle of talks about writing operators in Rust (I picked up Rust after one such talk, plus hearing that it was already in the kernel, and knowing that it was already in use at work)

Hopefully their APIs get better as they get more Rust experience. It'd be nice if, say, mutually exclusive stuff was something like an enum rather than just a handful of Option fields where actually setting multiple of them to Some is an error (no "make illegal states unrepresentable" here!), or if pyright didn't start yelling just because I'm trying to use a google API.

[-]

cloggedsink941@reddit

Go is completely unsafe. Go a bit outside of doing REST APIs and you're in full segfault land.

[-]

j4ckwh0@reddit

They are pushing it because in real world examples they have saved money having Rust code for certain parts of their code base. It actually gives Rust an enormous amount of credibility because these companies simply wouldn't be doing it if there wasn't a very real benefit.

[-]

Xatraxalian@reddit

If course there's a real benefit. It's blatantly obvious. The programming language doesn't let you do memory or thread-unsafe crap that would fail. That eliminates complete classes of bugs, which in turn saves a lot of money because developers don't have to go back again and again to fix broken code.

[-]

d_maes@reddit

Just using the right tool for the job. Rust for system-level, Go for for applications.

[-]

Dejhavi@reddit

I still think it is somewhat funny that Google is pushing Rust left and right even though they have Go

It's not just Google,many other companies are pushing Rust even though they have other "preferred" languages:Microsoft,Amazon,Meta,ARM,JetBrains...

[-]

syklemil@reddit

The google stories are also pretty interesting with the claim that vulnerabilities decay exponentially: By just writing new code in a memory safe language (e.g. Rust, but also most other languages that aren't C, or C++ (or Zig)) the avoid a lot of problems, as the problems arising from memory unsafe languages are generally discovered and patched over time (and hopefully patched before they're discovered by adversaries).

So they can take that sort of approach: Write new code in a memory safe language, harden and gradually eliminate memory unsafe code.

[-]

Dejhavi@reddit

The google stories are also pretty interesting with the claim that vulnerabilities decay exponentially: By just writing new code in a memory safe language (e.g. Rust, but also most other languages that aren't C, or C++ (or Zig)) the avoid a lot of problems, as the problems arising from memory unsafe languages are generally discovered and patched over time (and hopefully patched before they're discovered by adversaries).

That's what Google says...you don't have to rewrite everything in Rust,only the new code:

"Simply writing any new code in Rust reduces the number of new vulnerabilities and over time can lead to a reduction in the number of outstanding vulnerabilities,” the Android software engineers said, suggesting developers replace existing C functionality by writing a thin Rust shim that translates between an existing Rust API and the C API the codebase expects.

“The shim serves as a wrapper around the Rust library API, bridging the existing C API and the Rust API. This is a common approach when rewriting or replacing existing libraries with a Rust alternative.”

In the words of Mark Russinovich (CTO Microsoft Azure):

Speaking of languages, it's time to halt starting any new projects in C/C++ and use Rust for those scenarios where a non-GC language is required. For the sake of security and reliability. the industry should declare those languages as deprecated.

PS. Even the White House recommends using Rust

[-]

I_miss_your_mommy@reddit

Citing the White House in 2025 to support a claim is a wild take

[-]

araujoms@reddit

That's the 2024 White House. The current White House doesn't even know what is SQL.

[-]

ZCEyPFOYr0MWyHDQJZO4@reddit

We’re bringing back C, folks! The greatest programming language ever—no question about it. Boeing’s CEO came by, told me Biden wants Rust… total DISASTER! We want BIG jobs, BIG success, not complicated “memory safety” nonsense. DEI? More like DOA. #MAGA #BringBackC #AmericaFirst

[-]

araujoms@reddit

You jest, but I literally saw someone rambling about how Rust is woke and DEI and trans a couple of days ago. And it wasn't satire.

[-]

ZCEyPFOYr0MWyHDQJZO4@reddit

Well it is the language of femboy thinkpad linux users.

[-]

Pramaxis@reddit

I need that tattooed as soon as possible!

[-]

Ogmup@reddit

No it isn't satire, they're the usual culture war anti-woke crowd that are watching Lunduke and other stuff. Rust developers have become the same as being a vegan in their eyes. They have build the most negative strawmen possible and judge everything involving rust through this lens. In reality, for every actually annoying rust zealot (not a normal developers that likes to use rust), I see sometimes probably 40 - 50+ anti-rust comments.

Heck I watch Brodie Robertson from time to time and in one of his last podcasts he even mentioned how, whenever the topic has something to do with rust, he gets so many dumb comments from people who don't even know the very basics of computer science.

[-]

zenz1p@reddit

This is literally a Lundunke YouTube comment. Those ppl are schizophrenic

[-]

ang-p@reddit

Bit like the UK intern and the Excel COVID stats farce...

https://blogs.city.ac.uk/cityshortcourses/2020/10/13/what-really-caused-the-excel-error-in-nhs-test-and-trace-covid-19-system-an-in-depth-technical-analysis/

[-]

Dejhavi@reddit

Yep,even though the White House is a shit in 2025,it doesn't change the importance of the report they put out last year...even when they've fired the people who wrote it and taken it off their website

[-]

rich000@reddit

Honestly, it has bothered me for a LONG time now that the White House website is full of partisan political content, largely reflecting the opinion of a single administration. It isn't any better than the @potus twitter handle or whatever.

It isn't really a great place to host any kind of serious documentation. Admins end up redoing half the site because there is no real good way to go through and stamp out the previous admin's content that they disagree with and keep boring stuff like technical recommendations.

Then you get to the issue that even technical recommendations can get messy when you have vendors and everybody else under the sun influencing them.

Really I think programmers shouldn't be primarily relying on government sources as a place to host/drive recommendations. I get that there are smart people doing software development everywhere, but I wouldn't consider a US government website any more of an authoritative source on good software development practice than I would a Google or Microsoft website. I'm not saying the stuff there is bad - it just isn't some kind of authoritative standard.

[-]

I_miss_your_mommy@reddit

If it is from what was purged it has credibility

[-]

syklemil@reddit

Yeah CISO and Five Eyes in general recommend switching away from "memory unsafe languages like C and C++".

While they usually list Rust in conjunction with various garbage-collected languages, I suspect that what could be written in GC languages rather than C and C++ already has, starting especially with Java in the 90s, but also Node, Go, Python and others over the past couple of decades. So the stuff that remains is the stuff that doesn't play nice with a GC, possibly not even with a stdlib, where Rust is the most likely alternate candidate.

Some of them also want roadmaps to memory safety by 2026-01-01.

There's been a lot of discussion over in the C++ camp on how they can get off the naughty list: The borrowchecking style solution inspired by Rust was rejected back in november; the alternate "profiles" solution failed to get into the C++26 spec just a few days ago.

So likely the roadmaps will have a whole lot of "migrate to Rust" plans in them.

[-]

Rhed0x@reddit

Google was also experimenting with a rewrite of Binder in Rust, one of the most essential parts of Android, that is part of the Linux kernel.

[-]

Dejhavi@reddit

Microsoft too:

Microsoft is busy rewriting core Windows code in memory-safe Rust

[-]

adevland@reddit

Nobody is advocating to rewrite the entire kernel in Rust in one go

C has been around for a very long time. And that's not because of tradition.

Rust, on the other hand, advocates for "memory safe" coding by handling the memory management for you which, in turn, promises secure and bug free applications.

Let's be honest here. Secure and bug free applications do not exist regardless of what language you code them in.

If you replace one language with another you simply replace one set of problems with another. For rust we just haven't fully discovered the full set simply because it's new and that takes time.

This whole rust vs C discourse reminds me of the fanboyism around whatever js framework is popular now-a-days. You have these mini cult like communities that swear on the react/vue bible now just how they did for the angular bible 10 years ago or the jquery bible 10 years before that. Meanwhile, js is still going strong in the browser scripting space.

Now rust, just like react/vue, promises a lot of cool things while also introducing a lot of bloat and also encouraging developers to not do memory or even cpu performance improvements anymore because "the framework does it automatically. bro".

I'm not a linux kernel dev but I've personally witnessed the transition from performance being a priority to "readability" being a priority because of how bloaty these new js frameworks can be. And you're not making code safer in the process. Quite the contrary. The bloat makes it really hard to review and it slowly forces you to blindly trust the framework code. Your old problems are now the responsibility of the framework maintainers which are just as humanly flawed as you are. And you get new problems.

tl;dr: The more high level abstractions you make the more you lose in terms of performance and complexity.

[-]

adevland@reddit

@u/OOP1234, https://www.reddit.com/r/linux/comments/1it3owc/greg_kh_but_for_new_code_drivers_writing_them_in/mdqa76i/

people just need to git gud. Real man should program in assembly without the crutch of structs and variables and fancy language sugar.

That's a derogatory statement against education.

If you don't take education seriously then people will never improve and simply forcing them to use a new lang won't fix any of your app's problems.

[-]

OOP1234@reddit

You are correct. That's why we need to have forced re-education camp for bad programmers. Then we will never have bad programmers again and everybody will program perfect assembly.

[-]

adevland@reddit

That's why we need to have forced re-education camp for bad programmers. Then we will never have bad programmers again and everybody will program perfect assembly.

From the moment I understood the weakness of my flesh, it disgusted me. I craved the strength and certainty of steel. I aspired to the purity of the blessed machine. Your kind cling to your flesh as if it will not decay and fail you. One day the crude biomass you call a temple will wither and you will beg my kind to save you. But I am already saved. For the Machine is Immortal.

[-]

burntsushi@reddit

If you replace a horse-and-buggy with a motor vehicle, you simply replace one set of problems with another.

Technically, that's true. Using a horse for a mode of transportation has a totally different set of challenges than a motor vehicle. Sometimes a horse is even better! Yet to focus on this completely misses the point in a very obvious way.

and also encouraging developers to not do memory or even cpu performance improvements anymore because "the framework does it automatically, bro".

lmao

[-]

adevland@reddit

If you replace a horse-and-buggy with a motor vehicle, you simply replace one set of problems with another.

Finding an analogy that puts your own perspective in a positive light is something that anyone can do regardless of their own perspective. My point here is that if you do that you stray away from the technical aspects and venture into emotional territory. And that's when you need to stop.

lmao, you've got some good jokes

Not taking things seriously when they don't suit you is also part of the problem.

[-]

burntsushi@reddit

Finding an analogy that puts your own perspective in a positive light is something that anyone can do regardless of their own perspective.

Anyone can spout total bullshit too. Like saying that Rust encourages people to not do perf improvements.

[-]

adevland@reddit

Anyone can spout total bullshit too. Like saying that Rust encourages people to not do perf improvements, which is itself a profoundly unserious take. Your accusations are just projection.

Governments recommending that companies stop using C because it is memory "unsafe" is both bullshit and reality.

Uneducated devs write shitty and unsafe code. Simply moving to Rust won't fix that problem.

[-]

burntsushi@reddit

I'm not talking about what the government said. And I didn't endorse what the government said either. I'm talking about your bullshit.

So let's see now. First, you started with obvious lies ("Rust encourages people not to do perf improvements"). Second, you projected the flaws in your own commentary ("you're so unserious"). And now third, in the misinformation trifecta, you've resorted to blatant whataboutism.

I think we're done here.

*plonk*

[-]

you-cant-block-me@reddit

So let's see now. First, you started with obvious lies

I think we're done here.

plonk

Blocking me so I can no longer reply to you only proves that you cannot engage in a civil and argument driven discussion with other people. That only proves my point about how toxicity has no place in the Linux kernel development community.

Feel free to block this account as well. That'll show everyone how right you are. :)

[-]

linux-ModTeam@reddit

This post has been removed for violating Reddiquette., trolling users, or otherwise poor discussion such as complaining about bug reports or making unrealistic demands of open source contributors and organizations. r/Linux asks all users follow Reddiquette. Reddiquette is ever changing, so a revisit once in awhile is recommended.

Rule:

Reddiquette, trolling, or poor discussion - r/Linux asks all users follow Reddiquette. Reddiquette is ever changing. Top violations of this rule are trolling, starting a flamewar, or not "Remembering the human" aka being hostile or incredibly impolite, or making demands of open source contributors/organizations inc. bug report complaints.

[-]

AutoModerator@reddit

This comment has been removed due to receiving too many reports from users. The mods have been notified and will re-approve if this removal was inappropriate, or leave it removed.

This is most likely because:

Your post belongs in r/linuxquestions or r/linux4noobs
Your post belongs in r/linuxmemes
Your post is considered "fluff" - things like a Tux plushie or old Linux CDs are an example and, while they may be popular vote wise, they are not considered on topic
Your post is otherwise deemed not appropriate for the subreddit

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[-]

-o0__0o-@reddit

I don't want to hear about security from a manjaro user.

[-]

adevland@reddit

I don't want to hear about security from a manjaro user.

If you reject people based on their adherence to a group then you're only proving my point about the toxicity that has infiltrated the Linux kernel development community. There's no place for that here nor anywhere else.

[-]

-o0__0o-@reddit

I'm not part of the Linux kernel development community. I'm allowed to say whatever the fuck I want.

[-]

adevland@reddit

I don't want to hear about security from a manjaro user.

I'm not part of the Linux kernel development community. I'm allowed to say whatever the fuck I want.

So you are and I'm not? That must really make you special, huh? :)

Well, in that case I don't want to hear about ~~security~~ freedom of speech from a ~~manjaro user~~ hypocrite and a bigot.

[-]

adevland@reddit

I'm replying to my own comment here because u/syklemil blocked me.

The mainstream view here is that

And I'm voicing my opinion against it. And you blocked me.

The discussion is over because you want your way. Period.

My argument was specifically aimed against people like you who bully others into submission.

As far as I can tell you have nothing but drama arguments about how "mean" the people with technical arguments are

You just blocked me so you'd have the final word here. That speaks volumes about how petty you and other people in this community can be.

[-]

6e1a08c8047143c6869@reddit

And I'm voicing my opinion against it. And you blocked me.

No, they blocked you because you are very obviously arguing in bad faith.

You just blocked me so you'd have the final word here. That speaks volumes about how petty you and other people in this community can be.

You literally have a second account (/u/you-cant-block-me) to keep arguing with people that blocked you, and you have the nerve to call other people petty?

[-]

syklemil@reddit

Rust, on the other hand, advocates for "memory safe" coding by handling the memory management for you which, in turn, promises secure and bug free applications.

Let's be honest here. Secure and bug free applications do not exist regardless of what language you code them in.

This is a rather uninformed and bad take. To unpack it a bit:

Memory safety is a real thing that also governments are getting more serious about. It's a pretty narrow concept that basically just means you shouldn't be reading or writing the wrong bits of memory. Often just using a language with a garbage collector is enough; Rust is unique in that it brings memory safety without requiring a garbage collector.
Rust has a general focus on correctness as a core value; if you can't convince the compiler that something is correct, it won't let you do it. This is rather different from e.g. duck typed languages that will let you try your luck, or weakly typed languages which will just produce surprising results rather than errors.

Now rust, just like react/vue, promises a lot of cool things while also introducing a lot of bloat and also encouraging developers to not do memory or even cpu performance improvements anymore because "the framework does it automatically. bro".

This is just bizarre fantasizing. There's lots of resources about performant Rust, and the reason lifetimes get brought up as much as they do is because the compiler can't figure everything out automatically and actually needs devs to reason about their memory use. (Lifetime elision is pretty neat, though.)

You might want to spend a bit more effort on actually looking into things before you write rather long but ignorant comments.

[-]

adevland@reddit

This is a rather uninformed and bad take.

Often just using a language with a garbage collector is enough

You're criticizing yourself there, buddy.

No, blindly trusting your friendly neighborhood garbage collector isn't enough.

Rust has a general focus on correctness as a core value; if you can't convince the compiler that something is correct, it won't let you do it. This is rather different from e.g. duck typed languages that will let you try your luck, or weakly typed languages which will just produce surprising results rather than errors.

This isn't a Rust bashing/ass kissing contest. Stay on topic.

This doesn't mean entirely bug-free, but it means it can avoid certain categories of bugs, and alert the programmer to problems in their code than many other languages.

I'm all for that. But to go from that to bullying people that do not use the thing that you like is a few steps too far. And THAT is my point.

You might want to spend a bit more effort on actually looking into things before you write rather long but ignorant comments.

Vaguely insulting me simply because we have different opinions is exactly the type of bullying I was talking about.

[-]

syklemil@reddit

Often just using a language with a garbage collector is enough [to get memory safety]

No, blindly trusting your friendly neighborhood garbage collector isn't enough.

That's not quite my claim; the point is that when e.g. CISA start listing off memory-safe languages, they include bog standard GC'd languages like Java and Python. See e.g. appendix 1 in "The Case for Memory Safe Roadmaps" by CISA, NSA, FBI, et al

Memory _un_safety is a pretty rare problem that is most common with C and C++, which is why government agencies list those two languages as examples.

I'm all for that. But to go from that to bullying people that do not use the thing that you like is a few steps too far. And THAT is my point.

If you think governments making regulations and recommendations is "bullying" then you're kinda far out.

Vaguely insulting me simply because we have different opinions is exactly the type of bullying I was talking about.

You have no sources and you've made several false claims that show you do not understand the technologies you are critiquing. You're entitled to your own opinions; you're not entitled to your own facts.

[-]

adevland@reddit

Memory _un_safety is a pretty rare problem that is most common with C and C++, which is why government agencies list those two languages as examples.

It's a stupid take both when it comes to governments dictating code best practices and the CISA list of "bog standard memory safe" languages like you said.

It's an oversimplification for a problem that is not inherent to the programming language.

The problem is that companies cut corners and that results in shitty and unsafe code as well as uneducated developers. And you don't fix any of that by changing the programming language.

If you think governments making regulations and recommendations is "bullying" then you're kinda far out.

I never said that. And I don't like it when you make assumptions on my behalf.

You have no sources

I'm voicing an opinion that isn't an absolute truth. You can either discuss it or not. You making assumptions on my behalf only proves my point of this community being inundated by drama that has nothing to do with the technical aspects of what is being discussed.

[-]

syklemil@reddit

It's an oversimplification for a problem that is not inherent to the programming language.

The problem is that companies cut corners and that results in shitty and unsafe code as well as uneducated developers. And you don't fix any of that by changing the programming language.

[citation needed]

The mainstream view here is that memory unsafety is a specific thing relating to reading or writing the wrong parts of memory; this is really only possible from the programmers in some few languages that grant certain kinds of memory access.

Unless you're at the very least able to differentiate between memory safety and other kinds of safety, you're not bringing anything relevant to the technology discussion.

You making assumptions on my behalf only proves my point of this community being inundated by drama that has nothing to do with the technical aspects of what is being discussed.

As far as I can tell you have nothing but drama arguments about how "mean" the people with technical arguments are, plus your misguided and incorrect assumptions about how various programming languages work.

[-]

sayhisam1@reddit

I don't think this is a fair comparison.

Yes, there are framework cults - and abstractions can lead to overhead or complexity. But there have also been exceptions to this rule - C itself is one example of abstraction (over raw assembly) which improved the ecosystem in many ways. Static typing is an example of an innovation that eliminates bugs at compile time. And if you truly need the performance, you can still write bare metal assembly and embed that in your C code.

The argument is that the same is true for Rust - it is a legitimate innovation which embeds a new type of safety (lifetimes) in the compiler itself, which completely eliminates a class of bugs. Rust will stand the test of time as an exception to the norm.

[-]

adevland@reddit

abstractions can lead to overhead or complexity. But there have also been exceptions to this rule

The rule does not rule out exceptions and exception do not invalidate the rule.

My point is that you have to judge things on face value. If you blindly trust things then you will inevitably have problems.

Yes, there are framework cults

Rust will stand the test of time as an exception to the norm.

A lot of fanboys have said that about a lot of frameworks that have inevitably die out nad have been replaced by others that ultimately had the same fate.

Let's face it. When it comes to high level abstractions people simply cannot find common ground. And that's because the abstractions themselves can be done in multiple ways just how you can write good memory management code in C and simply using C itself isn't a problem.

This whole "Rust is a memory safe language" goes beyond simply iterating its features and has transformed into a campaign of demonizing people that do not code in Rust. If you don't code in Rust then your code is automatically unsafe in the eyes of many. If you do that then you're in a cult.

[-]

sayhisam1@reddit

If you hate abstractions so much then why not write everything in assembly? After all, it has very little abstractions. Stupid C compiler keeps hiding register allocations from me!! /s

It's just blatantly incorrect to say that people can't find common ground on high level abstractions. And high level is very subjective - to a Python or JS developer, Rust would appear to be much closer to the hardware.

[-]

adevland@reddit

If you hate abstractions so much

I never said that. You're abstracting it. :)

It's just blatantly incorrect to say that people can't find common ground on high level abstractions. It's happened before

Yes. Each cult has more than one member so it's not hard to find like minded people regardless of how crazy your ideas might be. But that doesn't prove anything. Popularity is not a factor here.

And you can't deny that when it comes to Rust the drama is unprecedented in the Linux kernel community.

I haven't seen so much vitriol here since the CoC was introduced 6 years ago.

[-]

sayhisam1@reddit

I can agree on the vitriol part. But it seems to be largely instigated by a few vocal minorities on both sides of the argument (same as with the CoC drama). It would undeniably be better for both if everyone just stuck with technical reasons for/against the RfL project.

[-]

adevland@reddit

It would undeniably be better for both if everyone just stuck with technical reasons for/against the RfL project.

Boom! That's it. :)

[-]

global-gauge-field@reddit

Personally, when writing Rust code, as far as performance goes, you have to be more specific.

You can check several benchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html

Rust is very high up there.

It is also not useful to talk in generic terms. If a person goes write very idiomatic code without any attention to performance, then they are gonna do it regardless of the language

or, they are gonna for specific libraries that already optimized these functionalities (sometimes using unsafe code)

Again, high performance code is hard and very diverse problem. See Agner Fog, and how big it is.

Just to give a specific example, you get mkl level performance for gemm problems using Rust because that the fundamental bottleneck is solved by writing inline assembly regardless of the language (and LLVM is not able to optimize it enough), you check here:

https://github.com/mert-kurttutan/pire

[-]

adevland@reddit

If a person goes write very idiomatic code without any attention to performance, then they are gonna do it regardless of the language

That's exactly my point.

Mandating that everyone switches from C to Rust won't make programs secure over night. Yet some people behave as if that were the case so they bully others into joining the Rust band wagon for no other reason.

You should not judge an app based on the language it was written in. Judge it by its own faults and virtues.

Heck, this whole drama sounds like we're making programming language discrimination a thing and I really don't want to be a part of any community that does that.

[-]

global-gauge-field@reddit

No, but Rust does offer is to eliminate memory safety issues in a way that is checked at compile time, which seems to be big pain in the Kernel according to Kernel. Just because it does not solve all the error, we should ignore the issues it solves (which Greg seems to agree with) I dont care and dont enough about people's reaction (social issues are too complex for me to make precise statements), just looking at Greg's statement and Rust in the Kernel.

But, we do judge the app based on the value it brings. The value it brings is associated with the language it is written. Just to show I am not blind Rust fan. If I were to develop fast and Deep Learning engine that can used for a write of accelerators, I would probably go for C+ because of the ecosystem around e.g. PJRT. Here, the value judgement is kind of depends on language because C/C++ bring somewhat unique value when it comes to this particular case. So, there is a transitive value judgement here. The same situation seems to apply in Greg's statement. We judge it by the value it (and the language it is written if applicable) brings.

[-]

adevland@reddit

Just because it does not solve all the error, we should ignore the issues it solves (which Greg seems to agree with)

Greg has a leveled take and I agree with him. But that cannot be said about the Rust bros out there that engage in social media bullying. That was my point.

[-]

newsflashjackass@reddit

This whole rust vs C discourse reminds me of the fanboyism around whatever js framework is popular now-a-days.

https://archive.is/1vwjR

It is no coincidence that Rust is being pushed by google. This is about as organic as wax fruit.

[-]

adevland@reddit

Good article.

The average lifespan of a “revolutionary” JavaScript framework is now less than four years. Companies spend upwards of $50,000 per developer annually on retraining and technical debt related to framework churn. Meanwhile, that COBOL system running your bank’s core infrastructure? It’s been humming along for 40 years.

We don’t demolish bridges because someone invented slightly better concrete. Yet we routinely scrap entire codebases because someone made a marginally better state management library. The software industry has become a pyramid scheme of knowledge, where the only real beneficiaries are those selling the next big thing.

Apart from the whole running cobol code thing everything else is part of each developer's yearly routine.

It's gotten so ridiculous that companies are now almost exclusively hiring "full stack" devs that are required to be proficient in a gazillion frameworks and tools that are part of the tech stack.

You don't make things better simply by switching to whatever is popular. That's just a lazy approach.

All mid to small companies do what big companies do and they justify it by calling it an "industry standard".

It's not an industry standard. It's a fashion trend.

[-]

N911999@reddit

There's some amount of misunderstandings from what you've said.

Rust, on the other hand, advocates for "memory safe" coding by handling the memory management for you which, in turn, promises secure and bug free applications.

If you read what Greg said you'd realize that that isn't what's being promised. Because of exactly what you said:

Secure and bug free applications do not exist regardless of what language you code them in.

Now, with that said, you can do 2 things, nothing, AKA the "get good" camp, or do the best we can, AKA the "let's use tooling and other things to help devs" camp. Can you guess which one works better in practice? Well, at least one camp has hard data on the topic. Now, you'll say "but that's on a different context it wouldn't be good idea to use Rust for low level kernel stuff", to which I remind you the fact that Microsoft is using Rust in the Windows kernel, that Oxide exists, that Rust is being used in safety critical contexts, or others... I don't know, I wouldn't think that Google, Meta, Microsoft, Apple, RedHat, Cloudflare, and others using Rust "just cause" makes sense.

[-]

adevland@reddit

If you read what Greg said you'd realize that that isn't what's being promised. Because of exactly what you said

I'm not talking about Greg. I;m talking about the general Rust community. Heck, even the Biden admin pushed Rust while discouraging using C as if doing that alone will magically fix your code.

Now, with that said, you can do 2 things, nothing, AKA the "get good" camp, or do the best we can, AKA the "let's use tooling and other things to help devs" camp.

The "get good" camp is a derogatory term for educating people. And that's a very good idea.

Switching to another programming language won't automatically make you good in it. You cannot avoid the "get good" aspect unless you really want to write bad code.

[-]

Misicks0349@reddit

i.e., as soon as something must be rewritten for whatever reason, THEN do it in Rust

I guess my question is how often does this happen, usually when the kernel needs something its added as a new feature rather then outright rewriting something, e.g. io_uring

[-]

UnshapelyDew@reddit

"Nobody is advocating to rewrite the entire kernel in Rust in one go, but if you can start writing NEW drivers in Rust, then replace older drivers with newer versions in Rust (i.e., as soon as something must be rewritten for whatever reason, THEN do it in Rust), then some new kernel functions could also be written in Rust. The Linux kernel could transition to Rust like that, for much safer programming. Granted, it'd probably take 10 or even 15 years, but good software projects aren't replaced or rewritten, they just slowly transition to something better over time."

That sounds naive.

[-]

small_kimono@reddit (OP)

Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We've turned our development model into a well-oiled engineering marvel creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem, we've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20+ years. We've got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together. thanks, greg k-h

[-]

deanrihpee@reddit

honestly, yeah, forget about Rust drama or whatever language, why's it become a problem adding some new language that's in experimental capacity? clearly dealing with compatibility, hardware abstraction or perhaps dealing with the actual hardware itself is much harder than adding a new language that is maintained by the expert at that language that's not even in full capacity yet, it's kernel, it is supposed to be complex, and why does Windows does not have any problem (seemingly) adding new language to their kernel stack with the goal of eliminating memory bug and security exploit? shouldn't Linux also aim for this? knowing that almost all servers uses Linux

[-]

billgytes@reddit

To give the C-only folks the benefit of the doubt. Most of them have been programming for decades. They have seen languages and maintainers come and go.

The last thing they want (from their perspective) is to have to support old code, in a language they don't like, because the Rust folks moved on to the newer shinier thing. Sadly, it's very likely that they have seen this before with other technologies.

Of course, it's my opinion that Rust is not going anywhere; its benefits are and should be painfully obvious to everyone; and having multiple languages in the kernel is a technical problem (which are the easiest types of problems to solve). So in my view as a user of linux there really is no excuse: Rust makes writing quality software much easier, which is all anyone should care about.

But it's easy to see how you logically get to a place of closed-mindedness with regards to such things.

[-]

ColaEuphoria@reddit

What's crazy to me are the people who think of Rust as a "shiny new language of the day" when it's been stable for 10 years now come May. Not even Zig has reached 1.0 yet.

[-]

billgytes@reddit

Absolutely!

But. It just simply takes a lot of time for things to develop mindshare.

To make a classic comparison, C came out in '73, didn't really pick up traction until the late 70s, and it wasn't really till the mid 80s that a conservative organization would seriously consider writing "serious" systems software in C, rather than assembler. Even still, large projects were done entirely in assembler until the early 90s!

Many conversations just like this were taking place, almost word for word, between programmers writing assembler and programmers writing C, in the mid 80s.

It simply takes a lot of time for these things to happen. Despite Rust's ubiquity in application code today, it is young. Although, again. Pretty easy to see the writing on the wall, that there will be a stable, growing position for Rust more or less permanently into the future for performance/safety critical systems work like the linux kernel.

[-]

round-earth-theory@reddit

While that's true of C's history, everything computing was slow to change back then due to the massive hurdles involved with collaboration. We had code that was distributed as printed text in magazines. So you can't apply the history of C in a straight manner like you're trying to any languages of today. Our modern tools and computing allow us to collaborate and evolve on a scale that would be unimaginable in the 70s. Modern devs can do in months what they took years to accomplish and that's all due to the better toolchains available today. What it doesn't mean is that 70s devs were smarter or more sophisticated because their projects took longer to mature.

[-]

Parking_Lemon_4371@reddit

It also doesn't really matter how long 'rust' as a language has existed, it only matters how long it has been in the Linux kernel... most kernel developers hadn't even heard of rust until \~3 years ago. It's still very early.

[-]

Flarebear_@reddit

I really like rust but saying it's a stable language is a bit much

[-]

globulous9@reddit

ten years of stability. nineteen years of development

still no spec. still no second implementation.

I would not undertake a large project in Rust until one of those two problems is fixed.

[-]

BiteFancy9628@reddit

It’s not about the language. It’s the people as always. He said. She said. There are valid arguments on both sides. But nobody is sharing the very valid fact that old school C kernel devs who don’t know or have any interest in learning rust are having an extra imposition on their (volunteer) time to review, merge and test rust code. And some of the rust kids have been pushy and not so respectful of their elders. Then of course Linus being a dick as he always is.

Personalities, not programming is the issue.

[-]

wintrmt3@reddit

Who is a volunteer? All the maintainers are paid by the foundation or some corporation to work on linux, this isn't 1995 anymore.

[-]

BiteFancy9628@reddit

Kernel developers include volunteers. Not all are full time

[-]

wintrmt3@reddit

Not simple developers, subsystem maintainers. J. Random Kernel Dev doesn't have to review other's patches if they don't want to.

[-]

toolman1990@reddit

Nobody asked them to Rust developers is responsible for their code and c developers is responsible for their code.

[-]

cloggedsink941@reddit

They can quit. People get sick and tired of their job all the time. And some of them are very hard to replace.

[-]

LotusTileMaster@reddit

Sounds to me like there is a lack of new maintainers willing to fill the role of the old maintainers. And the older ones do not want to learn something new to keep doing their hobby.

[-]

CitrusShell@reddit

It's not a hobby - the maintainers in question here are subsystem maintainers with one of the last words in what gets accepted and what doesn't. They are all employed by companies with an interest in Linux to do their work on the Linux kernel. The hobbyists in kernel development are people maintaining individual obscure drivers, who don't have much of a say.

[-]

Chippiewall@reddit

It's not just the lack of new maintainers, the old maintainers don't think new maintainers to help them are an acceptable trade-off towards Rust.

Ironically R4L is hopefully meant to be an answer towards this. Kernel C is it's own difficult variant of C (from all the Macros etc. layered on top of it to add safety) that's hard to learn, it's a significant hurdle towards new kernel developer. The hope is that Rust within the Linux codebase will be largely idiomatic - the extra "stuff" that kernel development relies on will be encoded into Rust language rules.

[-]

unixmachine@reddit

People keep repeating this, but it's not the fact. Christoph is not against Rust, he is against using multilinguages in the kernel, as it could be problematic. All this drama is just an argument between someone cautious against someone who risks more. Difference of experiences. Any other argument outside of this is conspiracy theory and a lack of understanding of what is being discussed.

[-]

simon_o@reddit

Christoph is not against Rust, he is against using multilinguages in the kernel

Suuuure, buddy.

[-]

Brillegeit@reddit

two old guys

Yeah, look at this disgustingly old man, he must be around 40 now, what a piece of shit.

[-]

simon_o@reddit

Any actual argument you would like to make?

[-]

bonzinip@reddit

Suuuure, buddy.

Straight from his mouth. You have no clue what and who you're talking about. I suggest that you inform yourself better before turning on the sarcasm.

[-]

simon_o@reddit

He is lying. If you are not smart enough to see it, I'm sorry.

[-]

bonzinip@reddit

Well, I have met him in person so I don't know dude.

[-]

simon_o@reddit

Yeah, so you are probably not the most impartial person to have an (incorrect) opinion.

[-]

northrupthebandgeek@reddit

Just because you've figured out how to abuse Reddit's block feature to force in the last word doesn't make your opinion any more impartial or correct than his.

[-]

small_kimono@reddit (OP)

People keep repeating this, but it's not the fact. Christoph is not against Rust

Read a little deeper. That's one argument. He has others and the others are facile.

[-]

ImSoCabbage@reddit

People keep repeating this, but it's not the fact.

People aren't even familiar with the basic facts, they simply invent issues to argue against, reality doesn't matter.

[-]

Delta-9-@reddit

Clashing of opinion, communicated through personalities that also clash. Yes, it's a people problem, wrapped around an opinion problem.

Every major conflict is a difference of opinion. People are what turn it into arguments, drama, even wars.

[-]

sadlerm@reddit

not so respectful of their elders

It's dumb that even Linux kernel development comes down to hierarchical notions of filial piety, but you're absolutely right.

Linux kernel dev is a club, and they don't want to let new people in for fear of losing control over their little fiefdom.

[-]

BiteFancy9628@reddit

But their complaints are also valid and no one even mentions them. It’s not only gatekeeping.

[-]

flying-sheep@reddit

old school C kernel devs who don’t know or have any interest in learning rust are having an extra imposition on their (volunteer) time to review, merge and test rust code.

No, why are you repeating this myth? As the linked mail says: New drivers in Rust, maintaining old stuff can and will stay C.

[-]

SweetBabyAlaska@reddit

Yea, and that's such a both sides take that makes no assessment about the state of things. I hate that stuff. We can't just strip all context and act like there are two sides who equally share blame, let alone assign blame at all as it is useless. There just has to be more nuance than "everyones wrong, I'm very smart"

[-]

Ok-Car-2916@reddit

That's not what happened with the new drama. The guy was pushing stuff outside of drivers, and then resigned, thus giving credence to the fears of the C maintainers that they would have to maintain. "We will maintain it for you and you don't have to.maintain our rust" is what the rust devs say, but then they tend to not stay around very long.

[-]

AyimaPetalFlower@reddit

You really think people would do that just go on the internet and tell lies

[-]

simon_o@reddit

That's like ... just completely made up.

[-]

klayona@reddit

Marcan wasn't the one pushing any code at all, this is plain misinformation.

[-]

hmz-x@reddit

I doubt that people with kernel dev level knowledge of C will have much of a hard time learning Rust.

[-]

ScalySaucerSurfer@reddit

It could be they just don’t want to and I think that’s (somewhat) fair. It’s not obvious how beneficial adopting Rust is in kernel land where you presumably often need ”unsafe”. Especially for someone who is very experienced and passionate about C, and dislikes Rust.

It’s very different than average corporate development scenario where you have juniors writing lots of ”safe” closed source code that nobody ever reviews properly as long as it works. It’s hard to argue against Rust there.

[-]

k0ns3rv@reddit

It could be they just don’t want to and I think that’s (somewhat) fair. It’s not obvious how beneficial adopting Rust is in kernel land where you presumably often need ”unsafe”. Especially for someone who is very experienced and passionate about C, and dislikes Rust.

One of the primary benefits of Rust is that you can isolate the unsafe code into small, auditable, sections and then wrap the whole thing in a safe API that's impossible to misuse.

It’s very different than average corporate development scenario where you have juniors writing lots of ”safe” closed source code that nobody ever reviews properly as long as it works. It’s hard to argue against Rust there.

This overstates how good more experience programmers are at writing bug free code, especially C. We have a lot of experience from the kernel and other C code that shows: even the most experience programmers still makes lots of mistakes that cause various security issues and bugs. Humans are just not very good at consistently getting precise details correct all of the time, we should embrace tools that help us.

[-]

MichaelTunnell@reddit

Windows has problems just by being Windows so language changes doesn’t really cause much issue when the main problem is perpetual. But seriously, Windows is developed being closed doors, we never see debates about language about Windows because of that, if they change language there is probably a fuss that happens but it happens in private

[-]

Tasty-Blackberry5772@reddit

Windows has added support for Rust and released some presentations. The Rust bindings are open source as well

[-]

BrodatyBear@reddit

Bindings might be open source but the discussion isn't.

[-]

Tasty-Blackberry5772@reddit

See https://www.reddit.com/r/rust/comments/12yg3cp/microsoft_rewriting_core_windows_libraries_in_rust/

The Linux kernel API is written in C, same as NT. The latter does have better laid out interfaces, relying a lot on typedefs rather than as much void* etc. More importantly there is a a custom type annotation called SAL (Source-code annotation Language) that actually provides static verification that lets you enforce stricter types.

Most NT kernel level third-party code I worked with use these, they help a lot for API definitions. Linux drivers and the kernel tend to be messy by comparison and harder to support a new language.

[-]

Dependent_House7077@reddit

why's it become a problem adding some new language that's in experimental capacity

it's become a problem when people started relying on said 'experimental' code. and kernel has much higher quality standards than anything else.

[-]

bonzinip@reddit

why does Windows does not have any problem (seemingly) adding new language to their kernel stack with the goal of eliminating memory bug and security exploit?

We don't know exactly what kind of Rust code is included in the Windows kernel and at which level of abstraction. Also, Windows has much more well defined APIs to write drivers with.

[-]

steveklabnik1@reddit

We don't know exactly what kind of Rust code is included in the Windows kernel and at which level of abstraction.

We do know some things for sure:

They re-wrote DWrite.
They've re-written at least parts of GDI, at first it was just part of it, but that news was a few years ago.
At least one system call, I forget if they said which one it was, is written in Rust

IIRC there's more too, like they offer packages to help you write drivers in Rust. But those were the first big ones.

[-]

bonzinip@reddit

DWrite is userspace, that's comparable to librsvg in Linux for example. I forgot about GDI, it is in the kernel but really shouldn't be. :)

I mentioned levels of abstraction because, based on https://scorpiosoftware.net/2025/02/08/writing-a-simple-driver-in-rust/, that would be very far from Asahi Lina's Mac graphics driver. But we have too little information to know what's really going on.

[-]

steveklabnik1@reddit

Good point about DWrite, this was all presented at the same time so I tend to lump them in together.

That post uses the stuff I was referring to at the end, yeah :)

Some folks are always disassembling new releases and trying to figure out what's there, but I can't remember what they've found.

[-]

Bakoro@reddit

and why does Windows does not have any problem (seemingly) adding new language to their kernel stack

Shit's different when you make $200k a year and someone can fire you.

[-]

deviled-tux@reddit

Rust is not in “experimental” capacity by any means.

[-]

ponton@reddit

Yes, mixed language codebases are rough

You mean C, asm and C preprocessor macro language?

[-]

mattia_marke@reddit

Or make, or cmake, or bash, or whatever magic they are using nowadays instead of an actual modern build tool like cargo.

[-]

Illiux@reddit

I'm pretty sure Cargo is not remotely up to the task here, so it'd be something else on top of it. Kernels need raw asm files, exotic linker options, etc.

[-]

mattia_marke@reddit

Ultimately you're right. We would need something that builds on top of it and we're not there yet, but there are already some solutions. cargo-make for example is a thing, and I think it uses a more descriptive syntax with its own Makefile.toml

The main point though isn't that cargo or rust is the best thing ever or even up to the task, the point is that when you keep using the complexity of the project (something very important that needs to be maintained for a long time) as an excuse to never switch to more modern, better solutions you're shooting yourself in the foot at some point in time.

If they really want Linux to succeed for the next 20 years, they need to do something about it now, I don't care what as long as it works. If not, then that's fine too, other more modern projects already exist.

I'm curious to know what projects like Redox OS are using for their builds 🤔.

[-]

Illiux@reddit

When I last worked in this space a few years ago on a hobby non-UEFI bootloader, I surveyed a lot of options and wound up back at plain old make. Everything else I played around with was either too inflexible, too language-specific, or both. Make's ability to be language agnostic while still supporting change detection in a pretty natural way won out.

[-]

mattia_marke@reddit

I see, it makes sense that they would still use make after all.

Though cargo-make doesn't actually depend on cargo to work, it is an executable just like make and it essentially works the same way but with a better syntax. Of course it can be integrated into cargo for building your stuff and you still need cargo to compile it.

[-]

mattia_marke@reddit

Also I just found this toy os project that demonstrates how it is technically possible to use cargo and ld to build an OS.

[-]

steveklabnik1@reddit

I have built a small operating system with Cargo before, that includes stuff like .asm files and exotic linker options.

That said, you are right that projects like this generally outgrow Cargo; the embedded OS we develop at work has a build system built on top of Cargo, because we have additional needs.

The kernel is not using Cargo.

[-]

Dependent_House7077@reddit

Adding another language really shouldn't be a problem, we've handled much worse things in the past

i highly doubt it.

mixed language codebase in a project that has significant internal churn is bound to be hard. until they figure out a solution.

linux kernel is stable from userspace pov, but inside it's undergoing huge changes every release. maintaining out-of-tree projects is often a lot of work, and maintaing Rust interfaces is not going to be any easier.

[-]

Misicks0349@reddit

I think one of the funniest things to come out of this whole rust drama was when rust folks are trying to figure out the invariants, lifetimes, and signatures for some function or another and are basically met with "IDK lol" by the maintainers, and when they looked at the drivers that used those functions they all used it differently.

[-]

Coffee_Ops@reddit

Is it possible that the issue truly is that Rust is asking maintainers to resolve years of technical debt and cruft in short order?

Maybe its true that no one knows the answer.

[-]

Misicks0349@reddit

"cruft and technical debt" is one thing, not having proper documentation and knowledge about the way the API you're maintaining is even supposed to be used by people is another

[-]

Coffee_Ops@reddit

If that's the situation they're in what do you propose? Dock their pay until they document the API?

[-]

Misicks0349@reddit

There isn't a solution that the kernel maintainers or certain stakeholders would like, docking their pay is wrong though and is a ridiculous idea.

But I didn't bring it up as some kind of call to action, but rather because its just looks a bit embarrassing on the kernel maintainers part, and frankly calls into question the quality of code in the kernel if even the people who are tasked with reading and writing it day-in and day-out don't understand it properly.

[-]

Coffee_Ops@reddit

"docking their pay" was tongue in cheek because they're not paid to deal with any of this.

I suspect if you told them you'd revoke their status if they didn't do it, they'd first laugh at your lack of authority, and then tell you not to threaten them with a good time.

[-]

round-earth-theory@reddit

The core maintainers are frequently paid to do their work. They spend way too much time on it to do it for free.

[-]

-Y0-@reddit

Document their API. Don't care how.

If you have rats nesting in the cables, because you didn't check them. Check them more often.

[-]

Coffee_Ops@reddit

Well go get started then

I hope you're not suggesting this is yet another thing the colonel maintainers need to do, because their overloaded backlog is a big part of the problem here.

[-]

-Y0-@reddit

Sure, just gib me access to highly sensitive kernel code :)

In seriousness, it's not my mess, but if it was, I'd spent extra time to sort it.

[-]

PDXPuma@reddit

Given that 80% of the kernel maintainers are doing it professionally for their companies, that's not a horribly bad idea. Just stop merging and start nacking their commits until they get their doc game in order

[-]

Coffee_Ops@reddit

Situation: Overloaded, underappreciated kernel maintainers doing the tough job that no one else wants.

Proposed solution: Pile more work on their plate and punish them for underperformance.

I'm not seeing this improve the situation.

I also suspect the companies paying them don't have these items as priorities and won't be willing to risk losing a valued employee over drama they don't care about.

[-]

lelddit97@reddit

assuming that that is true in all cases and won't net reduce burden since suddenly drivers become much more stable (on average, in most cases)?

I seem to be reading mixed opinions from maintainers, mostly on the positive towards rust. And if it enables more drivers to be written more easily and to be more stable then it kinda speaks for itself.

[-]

Albos_Mum@reddit

It's why I've been saying that the recent blowup with Rust and the various opinions shaken loose in the fallout of it shows that the whole way the Linux kernel is maintained is a tad dysfunctional and a bit of a rethink/brainstorm could go a long way to improving things, it's not just the difficulty that some (Not just the R4L devs either) have reported on getting big changes merged, it's also because it seems apparent that it's yet another symptom of the key maintainers being overworked when in a number of cases the stopping issue is less about actual technical issues and more that it's trying to convince the maintainer it's worth their time to try and learn/understand the code properly to work it into their codebase, or waiting for them to find that time.

I think one thing we can say for sure is that it'd help to get some extra bodies into the maintenance team, whether it's trying to convince more people to volunteer their time or by trying to convince the relevant companies that employing some more kernel devs is going to prove beneficial to them and others.

[-]

dali-llama@reddit

The beatings will continue until morale improves!

[-]

DankeBrutus@reddit

Developers not providing documentation? Say it ain't so! /s

[-]

-Y0-@reddit

Yeah. What is next? Forcing us to test our documentation and examples?

[-]

dreamer_@reddit

I see /s, but just as cool bit of info: in Rust it's totally possible to run bits of code examples from module documentation as tests, giving you additional check against devs forgetting to update docs. https://doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html

[-]

-Y0-@reddit

And you can embed tests and examples, which are compiled and run, as part of the docs! It’s pretty neat.

I think you can even run examples docs. That said, getting to debug doctest is still awkward to debug from IDE-like (VS Code, RustRover).

[-]

_zenith@reddit

Yup. You can’t forget to update the docs, because they’re generated from the code. And you can embed tests and examples, which are compiled and run, as part of the docs! It’s pretty neat.

[-]

doubled112@reddit

Just read the source!

[-]

josefx@reddit

Where does the "not having proper knowledge" come from? The entire argument started because the maintainer pointed the life time issue out when he was shown the rust API.

Just because you don't like the answer that the API leaves the life time of the object up to the specific implementation does not make it invalid.

[-]

phire@reddit

It's not really about fixing the technical debt. The people making Rust bindings mostly just want to document it, and cement that documentation as rust code.

The problem is that the simple existence of documentation has the effect of locking down the current behaviour (or quickly becoming outdated) and any kind of documentation as code locks it down further. It will become much harder to change the behaviour of any API with rust bindings.

Traditional C kernel developers have gotten very used to making breaking changes to interfaces and then just going around the whole kernel tree fixing anything that calls them. They won't be able to do that anymore.

Not necessarily because they don't know how to change rust code, but because rust developers will want to be very sure about any change to the bindings (or any code they call). The safety of rust code depends on correct bindings.

[-]

josefx@reddit

The answer was that the subsystem does not care, it doesn't need the data at that point in time, so it does not encode any requirements for it. If and when the data is valid is left to the drivers themselves to decide and document.

The rust developers where writing an ext2 driver, so they designed a rust API for all drivers that encoded the exact behavior of the ext2 driver without thinking if "every filesystem behaves exactly like ext2" is a valid abstraction.

[-]

GirlInTheFirebrigade@reddit

*"Idk, lol. Just do it like the other drivers did"

[-]

_zenith@reddit

“which one?”

[-]

studog-reddit@reddit

"Yes"

[-]

Karma_Policer@reddit

Laurent Pinchart reiterates this in the only reply to Greg's K.H. so far:

Looking at the two subsystems I know the best, V4L2 and DRM, handling the life time of objects safely in drivers isn't just hard, it's often plain impossible. I'd be surprised if I happened to have picked as my two main subsystems the only ones that suffer from this, so I expect this kind of issue to be quite widespread.

[-]

gizmondo@reddit

The theory is that rust bindings would come with C API improvements and fixes. However, when I expressed the fact that rust bindings for V4L2 would first require a complete rewrite of object life time management in the subsystem, I was told this was way too much yak shaving. As a maintainer facing the horrendous prospect of fixing this one day, I just can't agree to rust bindings being built on top of such a bad foundation, as it would very significantly increase the amount of work needed to fix the problem.

I find this point very important. He doesn't believe that the existence of rust bindings won't complicate reworkd of the misdesigned C side, despite the assurance that it will be other people's problem. That seems like a reasonable worry. But you can also understand the frustration of Marcan and co, trying to use some established C API and being told "nope, first go rewrite it from scratch".

[-]

campbellm@reddit

You can use a leading "> " to quote someone and it wraps in a sane way.

Looking at the two subsystems I know the best, V4L2 and DRM, handling the life time of objects safely in drivers isn't just hard, it's often plain impossible. I'd be surprised if I happened to have picked as my two main subsystems the only ones that suffer from this, so I expect this kind of issue to be quite widespread.

[-]

Karma_Policer@reddit

Thank you. I relied on Reddit's "quote block" functionality that actually wasn't a block at all.

[-]

josefx@reddit

when rust folks are trying to figure out

The fun part is that they spend four years working on that API without ever talking to any of the kernel people involved.

are basically met with "IDK lol" by the maintainers

A rushed presentation is not exactly the ideal place to discuss intricancies of API design, but it was more a "specific drivers may provide valid data, but it is not required at this point", only use it if you know what driver you are dealing with. The rust guys only ever looked at the ext2 code so they blindly designed an api with a type that required that the data would always be valid.

and when they looked at the drivers that used those functions they all used it differently.

And that is why the maintainer told them that encoding a lifetime guarantee in that specifc API did not make sense.

[-]

FollowingGlass4190@reddit

Just. Fork. It. For. Rust.

[-]

AnomalyNexus@reddit

There is also a case to be made for moving with the times.

C++ isn't going anywhere any time soon, but you also don't want to trend towards a situation like the banks where they're still sitting on a bunch of COBOL code and finding young devs with deep knowledge of it is functionally impossible. Banks solve that problem by throwing money at it. Kernel doesn't really have that ability - it's at least partially a passion project

[-]

newsflashjackass@reddit

What the Rust advocates should do is rewrite Linux in Rust.

When it is seen to impossible for the new Rust-in-Linux to have any bugs or ever crash, then everyone will agree that the whole project was not a waste of time.

[-]

budgefrankly@reddit

There already is a Rust kernel, Redox.

However some of the companies sponsoring Linux kernel development -- e.g. Amazon and Google -- want to reduce the number of bugs in the drivers they release, and so want to increase the amount of static analysis -- particularly memory analysis -- in kernel code.

The most straightforward way to do this is Rust4Linux.

[-]

newsflashjackass@reddit

Amazon and Google -- want to reduce the number of bugs in the drivers they release

...

The most straightforward way to do this is Rust4Linux.

I think I can conceive a more straightforward way to reduce the number of bugs in Amazon and Google's drivers.

[-]

poyomannn@reddit

I think you misunderstood the second point. It's "our drivers (in C) have too many safety related bugs, therefore we should use a memory safe language (rust). To viably do this, we need proper rust bindings that drivers can use."

[-]

newsflashjackass@reddit

Correct; and being charitable I am willing to credit it may be "the most straightforward" approach the user I replied to is able to conceive. I am even willing to believe the same of you.

As I already said, a less circuitous apparent is apparent. To belabor it for your sake: Bugs in drivers would be better corrected by altering the drivers themselves rather than demanding concessions from kernel developers.

[-]

bionade24@reddit

Have you even read the Gregkh mail? You can't just rewrite 30 Million lines of code, especially not without introducing some major new bugs. If a complete Linux rewrite in Rust is achieved in the next 5 years, only with the machine-transpiler that DARPA is developing rn.

[-]

newsflashjackass@reddit

No, Rust makes it so much faster and easier to write bug free crash proof code you are probably overestimating the difficulty.

Certainly it is impossible with that attitude.

[-]

simonorono@reddit

C++ language committee issues

What are these issues GKH is mentioning? (not a C/C++ dev, just curious).

[-]

syklemil@reddit

I think The two factions of C++ could work to explain. The first section (The absolute state of C++) has a bunch of (nested) bullet points, then ends with

I don’t know about you, but if I were to look at all of this as an outsider, it sure would look as if C++ is basically falling apart, and as if a vast amount of people lost faith in the ability of C++’s committee to somehow stay on top of this.

(The bullet points are too much work to copy-paste into a reddit comment box.)

[-]

HCharlesB@reddit

Thanks for the link. I'm going to check that out.

When I first (second, actually) tried out C++ I was ecstatic because it provided formal support for a lot of the things I was already doing in C and went beyond. I got to use it off and on in my professional career but since a lot of the stuff I did was in embedded systems (or in a shop that had standardized on C) I continued with C most of the time. At some point I did get back to C++ and felt that the language had grown a lot. I needed to learn it all over again.

Retired now, I'm using more C than C++ for hobby projects. Most recent one is 81 LOC, previous 263 (including comments and white space.) I could probably use rust for these.

[-]

syklemil@reddit

I could probably use rust for these.

Probably! People have varying experiences when they try to /r/learnrust; I found it fit my way of thinking pretty well, and I enjoy the compiler and clippy feedback. Others bounce off it; I suspect there's no way of knowing how one will react without trying it.

Embedded Rust I suspect has a different vibe, as there's a good chance you'll have to forego the stdlib (#[no_std]) and engage a bit in unsafe.

[-]

_zenith@reddit

Re: embedded Rust, I can recommend those interested in it to check out both the Hubris OS, and Tock OS.

Embassy, too, if one is looking for a lightweight, async-forward OS for small microcontrollers (like you’d find on an Arduino, for instance).

[-]

SV-97@reddit

Just guessing but the C++ committee seems to be sticking its head in the sand (to the point where they'll avoid mentioning Rust explicitly and instead talk about Ruby and the like when discussing safe languages).

It has shot down numerous efforts to make C++ more safe (like Sean Baxter's circle) and is now pushing profiles instead (that are regarded by many people as "too little too late"). They essentially want to keep doing what they've been doing for the past decades: no large changes to the language, favor performance over safety, and maintain backwards compatibility at all cost.

[-]

jorgecardleitao@reddit

Favor performance over safety sounds like a false dichotomy to me.

There is no evidence that Rust is slower as a result of its memory safety. In fact, it sometimes results in faster code due to the aliasing rules it uses, that LLVM can more effectively optimize.

[-]

SV-97@reddit

Favor performance over safety sounds like a false dichotomy to me.

It very much is, yes

[-]

syklemil@reddit

This email is a reply to someone digressing a Rust policy thread with their wish to add C++. Quoting a bit:

GKH on Rust:

The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)

and

GKH on C++:

C++ isn't going to give us any of that any decade soon, and the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time.

It's one thing to see various government agencies advocate against C and C++ because of memory safety, it's something kinda different to see the kernel second-in-command advocate abandoning C++ because of the commitee.

[-]

SergiusTheBest@reddit

I do agree that C++ doesn't enforce memory security but it allows to reduce errors by margin and plays nicely with C. There is no need to have 2 different compilers, bindings, code generation and so on. It was a mistake sticking to C and didn't go C++ decades ago.

[-]

mark-haus@reddit

C++ has been advocated ad nauseum for as long as I’ve been familiar with Linux (so decades, fucking yikes). It’s been rejected for the same reason for that many years and more. C++ doesn’t solve any problems the maintainers have with C

[-]

torsten_dev@reddit

wg16 is much better than wg21 about not polluting the language with cool but complex features.

[-]

PthariensFlame@reddit

WG16? Do you mean WG14 (the C language) or do you really mean the ISLISP standard last published in 2007?

[-]

torsten_dev@reddit

You saw nothing.

[-]

iAmHidingHere@reddit

Didn't the agencies just advocate to use memory safe C++?

[-]

Compizfox@reddit

What "memory-safe C++"? I'm not aware of such a thing.

[-]

syklemil@reddit

There is currently no memory safe C++. The C++ committee rejected "Safe C++" in November 2024, and rejected "profiles" for inclusion in C++26.

Currently the agencies use C and C++ as examples of memory unsafe languages in widespread use.

[-]

nonesense_user@reddit

https://herbsutter.com/2025/02/17/trip-report-february-2025-iso-c-standards-meeting-hagenberg-austria/

Regarding safety improvements.

[-]

mina86ng@reddit

Greg gets it.

Yes, for the next year… two years… three years maybe, the development of Linux will be harder including for existing maintainers. Best practices for coexisting C and Rust will need to be established. C maintainers might need to get at least passing understanding of Rust.

But after that period, life will be easier. If someone submits a driver written in Rust, maintainers won’t need to look at every single line of code to see if there’s UB lurking in it. They will be able to concentrate on analysing logic of the driver and concentrate more taxing safety review to the few unsafe blocks.

[-]

adevland@reddit

maintainers won’t need to look at every single line of code to see if there’s UB lurking in it

There's a very BIG difference between accepting an increased work load and decreasing your work quality and blindly trusting the authors because of that.

If the same levels of code quality cannot be enforced for rust commits because maintainers are not proficient in rust then rust commits should not be accepted. Period.

The rust community should be more patient and tone down their often ridiculous demands. Keep your "move fast and break things" mojo away from the Linux kernel.

It's highly hypocritical for them to demand the Linux kernel accepting rust patches and maintainers learning rust in a rushed manner while they themselves refuse to learn to code in C. You're either patient while the code quality processes are upheld or you GTFO.

And, yes, f ALL the drama. If you can't keep your frustrations away from the Linux kernel mailing lists then you have no place in this community nor should your demands be taken seriously.

[-]

Epithetless@reddit

"refuse to learn to code in C"

Just a FYI, R4L were also C maintenaners long before Rust became a part of the Linux project.

[-]

adevland@reddit

Just a FYI, R4L were also C maintenaners long before Rust became a part of the Linux project.

It doesn't matter if you were santa claus before coding in rust. Your rust code quality and your own technical arguments are the only things that matter.

This is about the technical side of the argument.

The rust community lost that battle in multiple instances and ultimately resorted to social media brigading and bullying to get their way. And that's not how you gain trust. That's how you lose it.

[-]

Epithetless@reddit

So I point out one factually wrong part of your argument and you immediately say it doesn't matter?

[-]

adevland@reddit

So I point out one factually wrong part of your argument and you immediately say it doesn't matter?

This is about the technical arguments. I've said so from my first comment. If you try to derail that by pointing out the past involvement of some rust devs then, yes, that's irrelevant. Your past involvements do not matter. The email you linked itself points out that trust or lack of it that comes from past involvements should not be a factor in the technical discussions. Trust itself does not matter here. Only the technical arguments matter.

Not really inspiring.

This isn't about inspiration. If you want to get inspired then go to pinterest.

You either have a good technical argument or you don't.

[-]

ChronicallySilly@reddit

This isn't about inspiration. If you want to get inspired then go to pinterest.

They clearly meant "inspiring confidence", but I feel you missed that in an effort to ping-pong back an emotional response

[-]

adevland@reddit

They clearly meant "inspiring confidence", but I feel you missed that in an effort to ping-pong back an emotional response instead of trying to see eye to eye and have a real discussion

People here have already vaguely insulted and blocked me for voicing my opinion against rust and its bullies specifically.

And if you think that my sarcasm is an attempt to trick you into making a fool out of yourself instead of treating as criticism then stop reading my comments and go find someone that will "inspire confidence" in you by blindly agreeing with your ideas.

[-]

ChronicallySilly@reddit

Dude this is just weird. I understand tone is hard on the internet but you've turned into "me vs. them" victimizing yourself. I'm sure people have been unfair, but if you want to have any kind of reasonable discussion on the internet you need to brush that off and stick to real arguments. Or else why post at all you're just getting yourself upset for no reason.

[-]

adevland@reddit

if you want to have any kind of reasonable discussion on the internet you need to brush that off and stick to real arguments

why post at all you're just getting yourself upset for no reason

Tell that to the families of the people that still receive death threats even after they stopped participating in the technical discussions.

You really have no idea how deranged some individuals can be and the lenths they can go to pursue their bullying.

If you don't care because it doesn't affect you then you're part of the problem.

[-]

ChronicallySilly@reddit

dude wtf are you talking about. I'm not talking about other people I'm talking about you, and now you're putting other people's suffering up as some defense of your behavior. Obviously people sending death threats are scum of the earth, you're deflecting responsibility for your own actions by trying to paint me as siding with completely unrelated things. Just be a little introspective about your own behavior if you want to have real conversations is all I'm saying. This isn't working anymore, I don't want to continue this conversation.

[-]

adevland@reddit

I'm not talking about other people I'm talking about you, and now you're putting other people's suffering up as some defense of your behavior.

What about me and my behavior? Nothing I've said so far is about me. If you think it is then you've missed the point entirely.

[-]

ChronicallySilly@reddit

Nothing you've said so far is about you. Everything I've said so far is about you. It's right there in the quote, "I'm talking about you". Please exercise reading comprehension

[-]

adevland@reddit

Nothing you've said so far is about you. Everything I've said so far is about you. It's right there in the quote, "I'm talking about you". Please exercise reading comprehension

Again, what about me and my behavior? How am I "deflecting responsibility for my own actions"? What actions are you referring to?

Why are you moving the goal post to talk about me?

[-]

Epithetless@reddit

Derail? Oh boy...

It's highly hypocritical for them to demand the Linux kernel accepting rust patches and maintainers learning rust in a rushed manner while they themselves refuse to learn to code in C

You were the one who called them hypocritical for not learning C.

Further validated by your other comment with another guy:

This is not about the technical aspects. Those discussions have been had and conclusions have been drawn. This is about the fact that the rust community is butthurt that they didn't get their way.

Now which is it? Is it supposed to be the technical aspects or not?

You also said this:

When your technical arguments have failed and your last resort is shaming people into submission then your ideas should be completely discarded.

And

If you can't keep your frustrations away from the Linux kernel mailing lists then you have no place in this community nor should your demands be taken seriously.

Let me put it this way: when your argument is to exclude others based on who they are, what they did, and their behavior, it is fundamentally a POLITICAL argument. Correcting you on facts about R4L's past becomes fair game, especially when you are using their failings to justify their exclusion and for their idea to not "be taken seriously".

To make matters more interesting?

You are not consistent. You move goal posts at your convenience. You bring non-technical points to the conversation, villainizing the Rust developers based on a myth. By your own logic, how can I expect to take you seriously?

Again. Not very inspiring.

[-]

adevland@reddit

Let me put it this way: when your argument is to exclude others based on who they are, what they did, and their behavior, it is fundamentally a POLITICAL argument.

I've already stated that engaging in social media bullying should not be tolerated on technical discussion forums. Or anywhere else.

Further validated by your other comment with another guy

Now which is it? Is it supposed to be the technical aspects or not?

You are not consistent.

As you yourself said, that was from another conversation I had with another person. What I said there does not apply here. You are taking my comments with other people out of context.

You clearly don't care about the original discussion and are only interested in attacking me personally at this point.

This discussion is over.

[-]

chaosking121@reddit

I need you to be trolling because otherwise I will be sad that someone can be this unreasonable.

[-]

adevland@reddit

I need you to be trolling because otherwise I will be sad that someone can be this unreasonable.

I'm not making demands. I'm voicing my opinion. You can disagree and I won't hold it against you.

My point is about other people that cannot take rejection and resort to things like online bullying and blocking dissent.

2 people here already blocked me for disagreeing with them. That goes well beyond being unreasonable. :)

https://www.reddit.com/r/linux/comments/1it3owc/greg_kh_but_for_new_code_drivers_writing_them_in/mdn5zni/

https://www.reddit.com/r/linux/comments/1it3owc/greg_kh_but_for_new_code_drivers_writing_them_in/mdn75p3/

[-]

Epithetless@reddit

As you yourself said, that was from another conversation I had with another person. What I said there does not apply here. You are taking my comments with other people out of context.

In the same comment I had linked, you quoted in reply to this:

I very much doubt that Rust kernel contributors refuse to learn C, given they dive into C code daily to understand how undocumented interfaces even work.

Which is almost in the exact same context of my original comment and this entire conversation. Surely, you are not being serious.

[-]

Epithetless@reddit

In the same comment I had linked, you quoted in reply to this:

Which is almost in the exact same context of my original comment and this entire conversation. Surely, you are not being serious.

[-]

KrazyKirby99999@reddit

You're correct that they know C, but it appears that some aren't willing to follow the same processes when applied to Rust.

[-]

MornwindShoma@reddit

The debate ends with a closing argument that Rust is here to stay and a new fresh document explains how. The "Rust community", if there was any, did ask exactly for this. The codebase *will* have more than just C. If you want to find any loser, you're not here to have a technical debate.

[-]

adevland@reddit

If you want to find any loser, you're not here to have a technical debate.

I'm not.

You're already labeling others as such.

[-]

MornwindShoma@reddit

There's no loser if everyone just wanted clarity, and clarity came out of this.

[-]

adevland@reddit

There's no loser if everyone just wanted clarity, and clarity came out of this.

If you get "clarity" by labeling others losers then you're the only "winner" in this because I don't want to play that game.

[-]

MornwindShoma@reddit

Find where I labeled people losers. Really. Try that. :)

[-]

adevland@reddit

Find where I labeled people losers. Really. Try that. :)

"If you want to find any loser, you're not here to have a technical debate."

I'm not here for a technical debate. I'm here to chastise the bullies. You found losers in what I said so, by all means, tell us who they are.

[-]

MornwindShoma@reddit

The fact that you're trying to stir some sort of emotional reaction instead of sticking to the technical arguments doesn't make you a loser, no.

[-]

adevland@reddit

The fact that you're trying to stir some sort of emotional reaction instead of sticking to the technical arguments doesn't make you a loser, no.

2 people here already blocked for disagreeing with them.

So, no, I'm not trying to stir anything. But a lot of people got really triggered when I mentioned the bullying problem, including yourself.

[-]

MornwindShoma@reddit

Uh uh, if you say so.

[-]

mina86ng@reddit

If the same levels of code quality cannot be enforced for rust commits because maintainers are not proficient in rust then rust commits should not be accepted. Period.

Where did you get that idea from? If anything, Rust will be reviewed to a higher standard because it’s going to be easier to review.

C and Rust programemrs are equally as smart. But C has more oportunities for bugs therefore C programmers will introduce more bugs.

[-]

adevland@reddit

Rust will be reviewed to a higher standard because it’s going to be easier to review.

Yeah, that's not what either side is saying.

C and Rust programemrs are equally as smart.

We're not debating that.

But C has more oportunities for bugs therefore C programmers will introduce more bugs.

And Rust hasn't therefore Rust programmers won't?

Nature always finds a way, bro.

Like I mentioned earlier, you're trading apples for oranges at best.

And I'm not saying that Rust should go. I'm saying that this whole superiority complex isn't helping you make friends.

[-]

mina86ng@reddit

And Rust hasn't therefore Rust programmers won't? That's a fallacy.

Not what I’ve said.

Like I mentioned earlier, you're trading apples for oranges at best.

No. I’m traiding watermelons for grapes.

And I'm not saying that Rust should go. I'm saying that this whole superiority complex isn't helping you make friends.

What superiority complex?

[-]

adevland@reddit

Not what I’ve said.

No. I’m traiding watermelons for grapes.

That's much better. :)

What superiority complex?

The one where you thing that "C programmers will introduce more bugs".

[-]

mina86ng@reddit

How is that superiority complex?

[-]

adevland@reddit

How is that superiority complex?

The problem with you not understanding this stems from your assumption that people that introduce "more bugs" in C will magically stop doing so in Rust. This assumption is false.

Your own choice supportive bias is clouding your judgement. You don't get better or worse at programming simply because you do it in a different language. If you think that you will then that's a superiority complex.

[-]

mina86ng@reddit

I’ve never said you get better at programming simply because you do it in a different language. But if a language prevents certain clasess of bugs, you won’t introduce those bugs if you write in that language.

[-]

adevland@reddit

I’ve never said you get better at programming simply because you do it in a different language

only that "C programmers will introduce more bugs". 🤡

But if a language prevents certain clasess of bugs, you won’t introduce those bugs if you write in that language.

Memory management bugs don't just magically appear if your programming language doesn't have a garbage collector.

If you think that people suck because they haven't made the same choice as you then you've got a superiority complex driven by choice supportive bias.

[-]

mina86ng@reddit

only that "C programmers will introduce more bugs". 🤡

Again, if a language prevents certain clasess of bugs, you won’t introduce those bugs if you write in that language.

You can write good and bad code in any programming language. Memory management bugs don't just magically appear if your programming language doesn't have a garbage collector.

No idea why you’re bringing garbage collector to the discussion, but yes, you’re right. The bugs won’t magically appear. The bugs will be introduced by programmers because programmers are humans who make errors.

If you think that people "will introduce more bugs" because they haven't made the same choice as you when it comes to what programming language they use then you've got a superiority complex driven by choice supportive bias.

I don’t think they will introduce more bugs because they haven’t made the same choices as I. What are you even talking about? I’ve explained why C programmers will introduce more bugs multiple times already. At this point, I can only assume that you purposfully misrepresent my position.

[-]

adevland@reddit

Again, if a language prevents certain clasess of bugs, you won’t introduce those bugs if you write in that language.

There are no programming languages that prevent memory management bugs. Rust sells itself as being "memory safe" but nothing is.

but yes, you’re right. The bugs won’t magically appear. The bugs will be introduced by programmers because programmers are humans who make errors.

And it only took repeating the same idea thrice for you to acknowledge it. Yay! :D

No idea why you’re bringing garbage collector to the discussion

Really? You have no idea what we're talking about here?

I don’t think they will introduce more bugs

I’ve explained why C programmers will introduce more bugs

You're contradicting yourself, mate.

Are you ok?

[-]

OOP1234@reddit

I agree with you. Language design doesn't effect bug rate at all and people just need to git gud. Real man should program in assembly without the crutch of structs and variables and fancy language sugar.

[-]

mina86ng@reddit

Really? You have no idea what we're talking about here?

I think you don’t because Rust has no garbage collector hence no need to bringing it up.

You're contradicting yourself, mate.

I am ok. You’re just misquted me. Here’s what I’ve said:

I don’t think they will introduce more bugs because they haven’t made the same choices as I.

Since you are now blatantly misquoting me, I’m going to end the discussion here.

[-]

you-cant-block-me@reddit

I think you don’t because Rust has no garbage collector hence no need to bringing it up.

Garbage collectors are features that "memory safe" languages boast in order for you to think that you cannot create memory management bugs in them.

And, no, we're not talking only about Rust here. You yourself have kept it in general terms by saying that "if a language prevents certain clasess of bugs, you won’t introduce those bugs if you write in that language".

I am ok. You’re just misquted me.

Since you are now blatantly misquoting me, I’m going to end the discussion here.

Trying to justify what you said with a "because" only to deny it in the same paragraph only proves your own incoherence.

And blocking me so I can no longer reply to your comments only proves my original point about how toxic this community is and how insecure you are about your own arguments.

[-]

UltraPoci@reddit

I very much doubt that Rust kernel contributors refuse to learn C, given they dive into C code daily to understand how undocumented interfaces even work.

[-]

adevland@reddit

I very much doubt that Rust kernel contributors refuse to learn C, given they dive into C code daily to understand how undocumented interfaces even work.

Your own doubts aside the fact remains that there is a lot of social media brigading and bullying that advocates for the increased adoption of rust. And that's really bad when your technical arguments have failed and your last resort is shaming people into submission then your ideas should be completely discarded.

The Linux kernel discussions are purely technical. When that changes and you resort to personal attacks to get your way and drama becomes the new norm then you can 100% expect quality and performance to suffer in the long run.

This is not about the technical aspects. Those discussions have been had and conclusions have been drawn. This is about the fact that the rust community is butthurt that they didn't get their way.

[-]

UltraPoci@reddit

"This is about the fact that the rust community is butthurt that they didn't get their way"

Except they did? Rust has been accepted as an experiment in the kernel. The problem is not that the Rust community is butthurt, the problem is that the decision of having Rust has been made, but some C maintainers refuse to collaborate, going against this decision. It's literally the opposite of what you're describing. The email in OP's link is about an important contributor giving technical details on why Rust makes sense in the kernel. If anyone is butthurt here are the C maintainers refusing to collaborate for some reason.

[-]

adevland@reddit

Except they did? Rust has been accepted as an experiment in the kernel.

Look at the social media bullying and tell the fanboys that they "won" because judging from their own toxicity it seems that they didn't or simply want more.

the problem is that the decision of having Rust has been made, but some C maintainers refuse to collaborate, going against this decision. It's literally the opposite of what you're describing. The email in OP's link is about an important contributor giving technical details on why Rust makes sense in the kernel. If anyone is butthurt here are the C maintainers refusing to collaborate for some reason.

That's not what I'm referring to here.

And yes, it's a good thing when those maintainers are no longer part of the community because they simply refused to collaborate for reasons that go beyond the technical aspects of this debate.

[-]

UltraPoci@reddit

The social media brigading was bad, but it was in response to the wrong doing of a C maintainer. This is not Rust contributors whining for no reason or because they "didn't won". It's not that Rust contributors aren't getting what they want, they are, the problem are some individuals gone rogue that oppose a technical decision on non-technical reasons.

[-]

adevland@reddit

The social media brigading was bad, but it was in response to the wrong doing of a C maintainer. This is not Rust contributors whining for no reason

The guy got death threats.

There are no justifications for that level of toxicity.

I also disagree with him while also disliking Rust but I would never engage in nor tolerate the shit that he went through. Nobody should.

[-]

UltraPoci@reddit

Dude, you said that the social media brigading was for the adoption of Rust, while this is not case because Rust has already been adopted. I agree it is bad, but you made it sound like Rust is bullying its way into the kernel which is absolutely not the case. I'm not here to argue whether or not the brigading was good or bad.

[-]

adevland@reddit

Dude, you said that the social media brigading was for the adoption of Rust, while this is not case because Rust has already been adopted.

I'm not debating semantics with you here. The rust drama is not over. People in the Rust community are not happy and they continue to make demands which aren't always met.

I agree it is bad, but you made it sound like Rust is bullying its way into the kernel which is absolutely not the case.

I never said that. Do not make assumptions on my behalf.

I'm not here to argue whether or not the brigading was good or bad.

Apart from making assumption on my behalf, what is your point here?

[-]

UltraPoci@reddit

"Your own doubts aside the fact remains that there is a lot of social media brigading and bullying that advocates for the increased adoption of rust."

Your words, man

[-]

adevland@reddit

bullying that advocates for the increased adoption of rust

Rust has already been adopted

Your words, man

Indeed.

Now run along and go tell that to the bullies.

[-]

UltraPoci@reddit

This makes literally zero sense and you're a waste of my time. Good thing you're in the minority and almost nobody agrees with you. Have fun on the internet I guess

[-]

adevland@reddit

This makes literally zero sense and you're a waste of my time.

In case you missed it my point was that, even though Rust devs "won" by getting Rust adopted in the Linux kernel, they still bully people.

Good thing you're in the minority and almost nobody agrees with you. Have fun on the internet I guess

It doesn't matter if I get down-voted. This is not a popularity contest and that's literally the main point of my argument.

If you can't wrap your head about how wrong it is for people to bully others into agreeing with them in technical debates they can't win with arguments then you're part of the problem.

[-]

burd-@reddit

When your technical arguments have failed and your last resort is shaming people into submission then your ideas should be completely discarded.

wasn't the cause of all this is Hellewig not wanting Rust in his subsystem that's not a technical reason?

[-]

bonzinip@reddit

I personally believe he was wrong but he does bave technical reasons, namely that he believes multi language projects become ossified and unmaintainable.

[-]

adevland@reddit

wasn't the cause of all this was Hellwig not wanting Rust in his subsystem which is not a technical reason?

so kernel discussions were not purely technical?

Yeah, and Hellwig was wrong.

When you still oppose something despite having no logical argument to do so, then you are clearly emotionally invested and my point is that there should be no place for people like that in the Linux kernel development community.

[-]

mooky1977@reddit

Why are you so hostile? Your defensive writing style here would indicate as much. Take a break. Seriously. You sound like you need to step back from that ledge my friend.

[-]

adevland@reddit

Why are you so hostile? Your defensive writing style here would indicate as much. Take a break. Seriously. You sound like you need to step back from that ledge my friend.

How am I being hostile? By discussing the hostility of others?

[-]

mooky1977@reddit

I think you may be projecting just a bit.

[-]

adevland@reddit

I think you may be projecting just a bit.

2 people here already blocked me for disagreeing with them. There is a lot of projection but I'm not the culprit.

https://www.reddit.com/r/linux/comments/1it3owc/greg_kh_but_for_new_code_drivers_writing_them_in/mdn5zni/

https://www.reddit.com/r/linux/comments/1it3owc/greg_kh_but_for_new_code_drivers_writing_them_in/mdn75p3/

[-]

steveklabnik1@reddit

A lot of the rhetoric around all of these situations has a framing of "Rust people" coming into the kernel, and then getting into fights with "Kernel people." It's often combined with various stereotypes of each group, that the Rust folks are younger, less experienced, that the kernel folks have been around the block a few times, etc. But that framing just isn't the case. The people involved are both: they've been working on the kernel for a long time, and then want to use Rust to improve it.

Just simply, your suggestion that this is driven by “Rust people” is wrong, let alone “refuse to learn C.” These are folks who have already been writing C code in the kernel for years.

[-]

barkwahlberg@reddit

Me: just casually checking the drama Kernel mailing list threads: >>>>

[-]

keithcu@reddit

I asked Grok if there were any good alternatives to Rust, and it had an interesting (long) answer that I posted to my website: https://keithcu.com/wordpress/?p=5033

[-]

HorkusSnorkus@reddit

Because Linux is now part of a commercial ecosystem and the number of Rust programmers is negligible compared to C systems programmers.

This might be an interesting science experiment but it shouldn't be a primary dependency of the core Linux kernel and support system.

[-]

ChronicallySilly@reddit

This is such a bizarre argument. Granted I'm not experienced enough to fully understand the details of the discussions around this but even being vaguely aware through Phoronix articles over several years now it's plain as day the Rust people are already here and have been here working.

Very rough TL;DR:

Rust people: "We've been working hard. Here's how C devs can make our jobs easier: please document your APIs :)"
C people: "No, we don't want to be responsible for that"
Rust people: "What? We're taking responsibility, we just want to know how your code works in a stable way so we can keep working on our implementations"
C people: "Absolutely not. We should be allowed to break code and it's too hard to have two languages in a code base."
Rust people: "What are you talking about?? We're not debating having two languages in the code base anymore the decision was already made and work is already being done. And if you break our code that's fine we'll fix it. We're just asking for documentation and eventually a stable interface which is good for everyone"
C people: "No. Because I don't think so." (*heavily paraphrased)
You: "Where are all the Rust people? Lets stick to C"

???? It's like you missed a few years of dialogue, work didn't start last weekend. How do you think all these Rust people were stepping down if they weren't already here?

[-]

budgefrankly@reddit

Both of these statements are false.

Because Linux is now part of a commercial ecosystem and the number of Rust programmers is negligible compared to C systems programmers.

The number of Rust programmers is exploding. Microsoft, Amazon, Google and others are hiring huge numbers of Rust developers. On the hobbyist front in just a few years a functioning OS written in Rust (Redox) has been created. The last time a significant number volunteers were motivated to create a new OS in C was back in the 90s.

Because old, proven code, is less likely to have nightmarish security bugs, race conditions, and other horror shows.

The Rust4Linux project has found cases in the current Linux kernel where C APIs were so poorly designed and documented that downstream C drivers made contradictory assumptions about memory lifetimes, meaning at least one had a bug.

Meanwhile Google has run the experiment in its codebases -- including Linux drivers -- and found that even just transitioning to a memory safe language for new code while retaining old code exponentially reduces memory bugs: https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

Also there's a third factual error implicit in this second statement: it presumes Rust4Linux developers want to replace existing APIs. They absolutely do not want to do this. They want to create safe Rust bindings for these APIs, but they need the C maintainers to document how they allocate, use and deallocate memory in order to do that.

[-]

-o0__0o-@reddit

Have you heard of the concept called learning?

[-]

Deathisfatal@reddit

Anything said by someone who says "C++ is a superset of C" can safely be disregarded. They're different (but similar) languages which have different standards and implementations for various things, even if you ignore the stdlib

[-]

eyes-are-fading-blue@reddit

It’s literally super set.

[-]

budgefrankly@reddit

This is absurdly pedantic

To any reasonable person aware of the context, and the bios of the people involved, it's clear he was talking loosely, i.e. that C++ was roughly-speaking a superset of C. That's the whole reason it's called "C++" for christ's sake.

The idea a kernel developer of his experience, who's had to dive into the nitty gritty of C and C++ compilers like GCC/G++ and C/Lang over the years is unaware of how void * is handled for example between C and C++ is bizarre nonsense.

Even with the divergence as C++ has gotten weirder with its bets on metaprogramming and templates, it is still the case that C interoperated better with C++ than almost any other language prior to Rust coming along.

[-]

GovernmentSimple7015@reddit

Not everything, I'm sure they'd have a pretty good idea of what the 90s were like

[-]

rbrownsuse@reddit

Greg, like always, gets it

What I think a lot of commentators are missing is this never was a technical debate of Rust vs No Rust

At its heart, this whole drama was a personality conflict between two stubborn individuals, one who thought they had a right to have their changes merged, and one with the right to block such changes

In order to change maintainer mindsets you need posts like this, not the route Rust devs took till now

I expect good things to follow if more take Greg’s example as HOW to engage in any FOSS development community, regardless of topic

[-]

small_kimono@reddit (OP)

At its heart, this whole drama was a personality conflict between two stubborn individuals, one who thought they had a right to have their changes merged, and one with the right to block such changes

I think this slightly misunderstands the history, in that the "one who thought they had a right to have their changes merged", those weren't his changes (they were Danilo Krummrich's), and the "one with the right to block such changes" had not such right (as they were to rust/dma).

[-]

sjepsa@reddit

Rust hates linked lists

[-]

wintrmt3@reddit

Safe rust forces you to write a correct implementation of linked lists, every "simple" one your wrote is a bag of UB and a security nightmare.

[-]

da2Pakaveli@reddit

I'd resort to other container types honestly. Doing an allocation for every insertion is much slower than allocating a buffer with reserves and if it gets full you up the capacity.

E.g. in C++, std::vector quickly outperforms std::list. I don't think that's down to the implementation. And the caching also leads to significant speedups due to memory alignment. With a linked list you need to fetch the next element from ram, which is slow.

[-]

yasamoka@reddit

There are hybrid data structures combining both (like deque). In the kernel, you can't not use a linked list for a few things.

[-]

sparky8251@reddit

VecDequeue is also an stdlib type in Rust.

[-]

Elnof@reddit

C++'s Deque is a very different underlying data structure than Rusts deque. I think that's what the parent post was getting at when they mentioned a hybrid data structure.

[-]

N911999@reddit

Yeah, it hates them so much, that there's one in the standard library, that one of the most famous rust tutorial is about them, so much that there's multiple linked lists crates including some used in a no heap context... Yeah Rust definitely hates them

[-]

sjepsa@reddit

So you can use rust standard library and crates in the kernel?

Serious question, no jokes, I am a bit 'rusty' in rust knowledge :-)

[-]

Botahamec@reddit

You can't. I don't think the kernel even uses the alloc built-in crate, which would also give you linked lists. The kernel re-implements parts of Rust's standard library to prevent panics. If they ever decide they want a linked list, they'll make one.

[-]

steveklabnik1@reddit

They previously had forked alloc but in my understanding all its patches made it upstream and they’re now using the upstream version. Even if that’s not true yet, that’s the end state.

Even then, the kernel wouldn’t want to use the linked list in collections, because the kernel wants an intrusive linked list, and this isn’t one.

[-]

N911999@reddit

Well, kinda, but you're lucky linked lists are in alloc, which can be used by R4L. Amazing isn't it?

[-]

syklemil@reddit

Clicking a little bit from the links, I suspect RFL is using kernel::list.

[-]

sjepsa@reddit

Great... Then I think that also standard library of C++ would be amazing in the linux kernel.

Probably would be easier to integrate with existing code

[-]

N911999@reddit

Oh wow, I never would've thought of that idea, it's not like someone literally said that and Greg is partially responding to it. It's also not like it's been an idea that's been floated around for decades and has been rejected because of technical reasons! But what would I know, it's not like all this things have been documented multiple times and are just a search away...

[-]

sjepsa@reddit

Yeah I see it is still discussed nowadays in the mailing list

https://lore.kernel.org/rust-for-linux/326CC09B-8565-4443-ACC5-045092260677@zytor.com/

Maybe it would require a week or so of integration, instead of decades like this new thing Rust

[-]

small_kimono@reddit (OP)

Rust hates linked lists

I mean -- there is one in the standard library? See: https://doc.rust-lang.org/std/collections/struct.LinkedList.html

You probably just should be using a vector for all sorts of reasons.

FWIW the problem with linked lists in Rust is that they are hard to implement. Do kernel developers need to continuously reimplement linked lists? Or is the problem dealing with the intrusive linked lists one already has in C, as a library (see above)? The kernel has its own red black tree, used everywhere, written in C too. Does that mean that kernel devs much continuously implement RB trees, or just interface with it as a library?

[-]

Coffee_Ops@reddit

As a complete amateur in this area I found Laurent Pinchart's followup to be a good read too-- it highlights some of the difficulties involved for maintainers without outright rejecting Rust or its benefits.

It makes one hopeful that there's willingness to work the issues constructively.

[-]

sparafuxile@reddit

Python developers 15 years ago:

"But we can develop a new version of Python, let's call it Python 3, we're developers goddamnit, we can maintain both versions for a couple of months and then we're done, it's a win for everybody, why shouldn't we do this?"

[-]

CoffeeTeaBitch@reddit

Are you arguing we should've stayed with Python 2?

[-]

pgetreuer@reddit

The (unfortunate) joke is that the transition to Python 3 took a decade, not a few months. Yet even now there are significant vestiges of Python 2, for instance, Vim contains stale Python 2 language bindings that were never upgraded to 3.

[-]

curien@reddit

So what? No one is claiming C should be eliminated from the kernel entirely, or even that new development should abandon C. Also Python 3 was intended to be incompatible with Python 2, whereas kernel Rust is intended to be compatible with kernel C. It's just a completely nonsensical analogy.

[-]

pgetreuer@reddit

Well, yeah. I don't think anyone is saying the Python 2/3 situation is the same, because, yeah, it's not.

The relevance to Rust for Linux is as some indication of how long significant migration projects might take, being a recent example of one. That's not to say that such projects should never be done—the long-term benefits of Rust for Linux are compelling—just to expect that this will take a while to get there.

[-]

molniya@reddit

It isn’t a migration project, though. The idea is to make it possible to write kernel code in Rust rather than in C, with the Rust code being able to coexist with and use the C code. Nobody is proposing to rewrite the entire Linux kernel in Rust.

[-]

sparafuxile@reddit

No, I argue that the boring maintenance effort should not be underestimated. Wishful thinking can and does happen.

[-]

budgefrankly@reddit

Ultimately the bet on Python 3 paid off, and the project was able to handle a long period of dual versions pretty smoothly while everything that mattered made the transition.

Is this your argument for Rust in Linux?

[-]

sjepsa@reddit

You pay a lot in migration just to have a small guarantee about a couple of different bugs

[-]

small_kimono@reddit (OP)

You pay a lot in migration just to have a small guarantee about a couple of different bugs

But for new code / drivers, writing them in Rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this?

Don't think anyone is arguing for any migration yet?

[-]

syklemil@reddit

Migration would only be something to discuss once the RFL projects in Rust (2024H2, 2025H1) are done and GCC codegen is in place or something else to ensure that no current Linux platforms are incidentally dropped.

The RFL project is still in an experimental phase; presenting it is a migration project is essentially misinformation.

[-]

Botahamec@reddit

FTR, those RFCs are already implemented on nightly Rust, which is what the kernel uses. Those issues are for moving those features into the stable channel.

[-]

syklemil@reddit

Yeah, and I think being able to build with the stable rather than nightly compiler would be considered a prerequisite to moving on from considering the RFL project an experiment, considering actually migrating code, that sort of stuff.

There's a lot of interesting work going on, and already working Rust in Linux (with the Apple M4 as the most prominent example?), but it's still in an early stage. (As evidenced by the friction from C devs who turned out to be C purists.)

[-]

steveklabnik1@reddit

The kernel technically already compiles on stable. What they do is:

Only support one rustc version
Abuse an environment variable that allows unstable things to compile

This works fine until they want to support a larger range of versions, in which case things start to get dicier, which is why everyone wants it to truly work with stable Rust. Rust will be ready for that before they are, I bet.

[-]

-o0__0o-@reddit

The that recently. There's a range of supported versions now. See the FOSDEM talk.

[-]

steveklabnik1@reddit

Ah ha! Thank you! I missed that.

[-]

N911999@reddit

I'll link Google's experience with oxidizing android https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

[-]

MisterCubby@reddit

Greg and Linus need to go. The clowns are running the circus.

[-]

Professional-Disk-93@reddit

It's all over for cniles.

[-]

ElMachoGrande@reddit

I strongly believe in keeping the tool chain simple, and that means, among other things, no parallel tools. If something is to be done, select a tool and stick to it.

At some point, it may make sense to gradually replace stuff with a new language, and during that transition have two languages. However, that should only be done when you have a mature, trusted and tested alternative, and after very serious and deep consideration. It's not something to be done just because a dev has a favourite tool.

[-]

N911999@reddit

However, that should only be done when you have a mature, trusted and tested alternative, and after very serious and deep consideration.

Does Google, Meta, Microsoft, Apple, RedHat, Cloudflare, and others using Rust for security sensitive code and in general count as evidence of this? Does the experience of android team count?

It's not something to be done just because a dev has a favourite tool.

Oh, so we agree on that? That's great, cause it's not like Greg just talked about some of the technical reasons why the R4L project exists

[-]

FlukyS@reddit

> Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible

This is such a weird thing to call out originally even. Like sure having 2 languages means you can't easily share reviewers for that code if the current ones aren't familiar but the whole point of using Rust is to leverage the safety and tools of the language to allow for easier/faster hardware enablement. Also given the size of the kernel itself it isn't a bad idea to have split maintainers up as long as it makes sense and for drivers vs other parts of the kernel internals it really makes sense.

The whole thing I think people are dancing around is that they believe adding Rust is a slippery slope to removing C completely and that is scary. They see it as a red line that should never be crossed for whatever reason be it just liking C more or just not wanting to adapt to new languages. Rust isn't C but it is fast, it has some features to help limit bugs and when dealing with hardware integration from external parties that is a big deal and it is friendlier than C because it handles memory management and garbage collection. Those sorts of things are worth the tradeoff.