Was Rust In The Linux Kernel A Mistake?

[@PhilfreezeCH]

Even ignoring the Rust aspect, you have some people saying „could you please document what args your function accepts, what it does with memory so people know how to use it?“ And the current maintainer answering „nah, I don‘t feel like documenting my code“. Why are we even talking about this, it should obviously be documented. Be it as Rust syntax or as a poem written in a separate text file.

[@torsten_dev]

Yes. My next project will require all functions prerequisite to be documented as Haikus. Would filter all PRs out that don't read the style guide.

[@thegoldenatlas753]

This is literally it. These are lazy devs with fat egos refusing to document information Rust makes clear by default. That's why they hate Rust. Rust strips them of being treated like a god every time there's an issue with the code and makes it so other people can maintain the code.

[@tuttocrafting]

I've tried multiple times to develop a simple kernel driver. Each time I have to reverse engineer the sh!t out of existing driver to figure out what the hell structs and methods accept. I've always found that the Linux kernel is a nightmare for new developers. I've tried on multiple subsystems (also, net, and iio) and the things is almost the same. The only piece of documentation you can hope for when reading a subsystems or a driver is the mail list.

[@BlakeyPark]

@@thegoldenatlas753 Rust developers think they are the be all and end all of everything. If anyone has an ego, it would be the Rust developers. This is why most everyone dislikes them, sure, the C developers could be more accepting but Rust developers need to look at themselves first. This is why people don’t mind Rust, what they don’t like is the Rust community, it is toxic and they tend to bring drama wherever they go.

[@thegoldenatlas753]

@@BlakeyPark Rust developers are far less likely to have an ego. The entire premise of rust is "the programmer is fallible and needs rules to code well" that is the exact opposite of an ego. Ego conveniences you that your perfect and that everyone else is wrong, Rust makes you admit your aren't perfect.

[@gokhanersumer2273]

"I refuse to document my code because it may change!" Its a great mindset, if you're building a castle of cards.

[@kensmith5694]

I always document my C code with some more C code in comments that does something completely different.

[@gokhanersumer2273]

@@kensmith5694 Thats even a greater way to crash all your callers. Job well done!

[@mkabilly]

yell at Uncle Bob as much as you want but he was right when he said that the only _actually correct_ piece of documentation you have is the code itself.

[@mezzer34]

Its the kind of behaviour that makes me transfer off a project at work lol

[@gokhanersumer2273]

@@mkabilly I'm not talking about external documentation anyway. I aggree code is the ultimate documentation but still, even out-of date-comments might be better than zero comments figuring out why and how code evolved, assuming you use version control.

[@otterlord]

The only true solution is to rewrite it in JavaScript

[@user-dc9zo7ek5j]

npm install Installing 3489248825678683689234929482458712385283582588 packages (200 TB)... -----/--------- Finished Please support npm Something something npm audit to fix everything CRITICAL: 93599248921389 SERIOUS: 92834582582 MEDIUM: 299582 RARE: 2189.

[@Nina-cd2eh]

The userspace of course must be rewritten in the latest JS framework to keep up with the industry. Can't think of a more elegant solution

[@BrodieRobertson]

I vote for scratch

[@inotopia]

Too true.

[@quaesitrix881]

What heresy... The one true answer is a rewrite from C to Holy C.

[@BrentMalice]

this never wouldve happened if they just chose Holy C instead. demon safety > memory safety

[@cchutney348]

I find memeing the seriously mentally ill extremely distasteful, disturbed genius or not.

[@phoneticalballsack]

haha tempel os funny

[@BrentMalice]

@@cchutney348 alrighty

[@infinitelink]

​@@cchutney348those who meme Terry, love Terry. RIP.

[@BrentMalice]

@@cchutney348 since most linux users are robots, id like to let you know that most humans will use humor to cope with tragedy. hes better than most of us will ever be, but also refused help and treatment. theres a lot to learn from keeping his memory alive, even in meme form.

[@emilyhelms-tippit4053]

I feel like if some people want the kernel to be all Rust, and some want it to contain no Rust, the answer is clear: every even line of source code is C, every odd line is Rust.

[@nullvoid3545]

Adding one line is A major refactor, but adding two is perfectly fine!

[@johnc3403]

And have the respective odd and even lines merge into a single line in a new language called Crust. One that looks like C but works like Rust. Happy days, happy devs.

[@JorgeDB]

Oh... now Rust enthusiasts will write all files in a single line to have only rust in the kernel

[@_xX_me_Xx_]

@@johnc3403 oh boy

[@funkijote]

Sounds good, then we can use Swift’s something or other to actually make it all work. Swift 6 is ready for kernel-level action.

[@basilefff]

I don't know anything about developing in kernel space, but it seems to me that if most DRM drivers encounter bugs because of undocumented code and difficult to track lifetimes then it really isn't Rust in Linux issue, it is kernel API issue, Rust is just forcing everyone to clearly define things, which seems like a good thing to me.

[@mmstick]

That's essentially what the whole discourse is about, but the peanut gallery wants to make this about a problem with Rust rather than with maintainers refuse to collaborate.

[@HaydonRyan]

This is where everyone needs to agree that “correctness” and no “ambiguity” is the answer.

[@gabrielbarrantes6946]

What the hell... C forces you to define everything. Stop praising Rust for stuff that C already does quite well.

[@blazewardog]

Had similar issues at my job when we started switching to TS from plain JS. Half of the better development since has been since the language forces more documentation.

[@infinitelink]

​@@blazewardogC already self-documents because it is so low-level it is simple to read if you took the time to get trained and educated properly to do systems development. Indeed C is the more stable,simple, clear language. Rust does not have a standard, second implementation so it is not allowed in critical systems--no second implementation means no verifying behavior or accountability of those developing the language--and indeed as expected from a lack of a second compiler, Rust keeps breaking itself between versions that aren't supposed to (non-majors). It is still interesting and awesome, just isn't by any standard founded empirically a language that has reached maturity for systems use. Source: reading the books used for aerospace right now. I'm hoping to get to Rust in a few years too.

[@liarus]

All i see on the video:"Hello, can you please explain how we are supposed to interact with~" "YOU WILL NOT FORCE ME TO USE RUST!"

[@Blink_____]

that was my takeaway too

[@tato-chip7612]

I remember when microkernels were the thing that would kill monolithic kernels. No linux won over unix due to a combination of luck, the license and the fact that it was free unix.

[@bigpod]

problem is from my understanding that linux is basically few steps from being like perfect middleground

[@user-dc9zo7ek5j]

Linux won over not only because it was free, but also because it had a working version.

[@stefanalecu9532]

That's how C won: because of a shitty OS filled with hacks cosplaying as a mainframe... I meant Unix :) We could've had a better future, but Ritchie chose to ignore Pascal

[@NoNameAtAll2]

did you forget a comma?

[@blzrL]

​@@stefanalecu9532L C is better

[@jor_r8769]

Boomers vs. furries. Linux community in a nutshell these days.

[@meanmole3212]

lmaooo

[@purpasmart_4831]

You can be a C dev and a furry, its not mutually exclusive.

[@alen2937]

@@purpasmart_4831 No but apparently it IS for RUST developers.

[@mek101whatif7]

Lina is dweeb though

[@systemchris]

​@@purpasmart_4831not all furries do rust, but all rust devs are furries?

[@diametheuslambda]

This all sounds like "But ma, I don't _wanna_ document how my code behaves. You can't make me." And that's not a sound filling me with confidence for a complex, critical project that needs to coordinate thousands of people.

[@HaydenLikeHey]

Yeah, I honestly can't believe they've gotten this far while this far into darkness.

[@SuperSmashDolls]

⁠@@HaydenLikeHeyLinux is too big to fail. They get shittons of bug reports and QA work purely by being the one big UNIXlike everyone uses, so if a maintainer pushes through a big refactor without documentation and just fixes things to where they sort of compile (which works for Rust, NOT C) all the security bugs will get caught (we hope) and fixed (we hope).

[@thewhitefalcon8539]

If you don't like it, you maintain that area.

[@OMGclueless]

I don't think that's the argument. It's not that they don't want someone documenting the current behavior of their code. It's that they don't want to be responsible for software written in other languages when they change the behavior of their code. I have a lot of sympathy for this. In a large software ecosystem, such as in a monolithic repo at a large software company, a lot of speed is gained when the people maintaining core libraries have the ability to make breaking changes by updating all of the callsites of their code as they change the code's behavior. If one of those callsites is a Rust binding whose lifetime or type system guarantees they are now breaking, then they no longer have the skills to do that and no longer are capable of changing their own code without breaking the Linux kernel.

[@mattmurphy7030]

If I change my library code, it’s not my responsibility to fix all the tools that use that library. It’s the tools maintainers. That simple

[@ZeroUm_]

Imagine trying to document an API and being attacked for it.

[@isodoubIet]

Documentation has no behavior so that's clearly not the issue.

[@RichardDressler]

fn main() { tell_the_government_everything(9, '11'); } Why wasn't this function documented. 🤨

[@secretzpt176]

@@isodoubIet Huh? That's literally what the RfL team is asking for, how can that not be the issue...

[@isodoubIet]

@@secretzpt176 Maybe listen to what the actual guy is saying? He's not worried about irrelevancies like what flavor of sugarcoating was picked this time, he's worried about the _actual system impact_ of encoding semantic information in the type system of a very different language. Again, like he said: what happens when he wants to change the API in the future and there's a bunch of code written in a different language that has to be updated too? Is he supposed to just break the world? That's not how development works.

[@secretzpt176]

@@isodoubIet What the actual guy in the presentation said was that he wants to get notified of changes, Asahi Lina has also been outspoken about wanting clearer documentation. You're making it sound like the Rust developers want the C devs to update Rust code they break, when this is explicitly not what they are saying. If kernel devs are unwilling to properly document their code, which they should be doing regardless of Rust, then that seems to be a much greater issue...

[@LarixusSnydes]

Whether in C comments or in Rust, good documentation is crucial for maintainability, security and auditability of code written. I'm not versed well enough in Rust to decide for myself whether Rust can provide all the functionality that C provides. If the majority of severe security errors in kernel code stem from memory issues that Rust doesn't have, than that is a good argument for using Rust. What I am worried about is that too much energy (and eventually people) will be lost to Linux kernel development because of an unwillingness to cooperate and discuss things rationally without too much emotion and ego getting in the way of things.

[@experimentalcyborg]

💯

[@JustSomeGuy009]

Then go develop a kernel in rust instead of trying to change the fundamental core of an existing project with decades of work. Why do people always want to enter into a space that they don't agree with and want to change it until it is unrecognizable? Make your own space.

[@fiona9891]

​@@JustSomeGuy009 are we still talking about software?

[@the-answer-is-42]

​@@JustSomeGuy009 I think a more pragmatic approach than "make your own space" is preferable in a project as critical as Linux. And asking for better documentation is hardly unreasonable, especially since that will likely also help the C developers.

[@q2yogurt]

@@JustSomeGuy009 you're one of those people with too much emotion and ego he's talking about in this comment. Stop being a fucking child.

[@guyblack9729]

They should just propose Haskell in the kernal to get everyone mad and make Rust in the kernal sound nicer

[@elaps]

I love the idea of a new kernal space program

[@TrackballClick]

Yeah. Take a language, and for better self-explanatory character of it, remove all the parentheses and add some more spiciness with partial application, then let people read the work of others. The first who writes a code will have clear advantages compared to those who have to read and guess the intent.

[@nangld]

But Haskell is actually good and safe language! Haskell also filters out script kiddies.

[@Zirkorn]

True​@@nangld

[@shaggygoat]

Them’s fightin’ words! FORTH is the only true language! 😀

[@tato-chip7612]

let's be real: everyone knows the moment you work on an established codebase and you try to retrofit a new language on to it you get issues.

[@_Safety_Third_]

Yes, this is why I'm thinking, maybe Linux should stay C language only, knowing this will eventually mean its demise. Rust is a better language, but trying to hybridize and convert over to it is possibly just too difficult to be practical. Eventually someone will come along and create a Rust kernel, and years after that it will begin to supplant Linux. Linux will stick around in some form for decades, but it was never going to last forever anyways. (edited for spelling) Thoughts?

[@user-dc9zo7ek5j]

Yes, all the new problems that will come will be blamed for the new way of doing things. Of course it is normal for new solutions to cause different problems, but if people don't get over them and accept that they must learn and work additionally for this new solution, even if it was better (as they claim rust is) then it will be doomed to fail. That's why a lot of people lean into C++ because it is a step up from C. The problem is that Linus does not like it, because ironically it also requires additional learning and effort. I think C++ is the closest language to home and the most appropriate solution for now.

[@BlakeyPark]

@@_Safety_Third_ While Rust offers memory safety, merging it into the Linux kernel is a poor decision. The kernel's decades of success with C highlight its reliability and performance. Rust's architectural limitations and the lack of expertise among maintainers pose significant challenges. Instead of complicating the kernel, efforts should focus on developing a separate Rust-based kernel. Linux has a huge community and a proven track record, I don’t believe it’s going anywhere anytime soon. To note: C is not perfect and it does have issues, but we shouldn't rush to adopt newer languages like Rust simply because they are deemed 'better.' Rust's memory safety is appealing, but its integration could disrupt the kernel's stability if not handled carefully. While I program in both Rust and C++, I believe Rust is often placed on a pedestal higher than it deserves.

[@TerrorByte69420]

b-but m-muh MEMORY SAFETY!!! IF YOU DON'T INCLUDE MY SHITTY LANGUAGE YOU'RE GONNA HURT MY FEELINGS!!!!

[@jonnyso1]

The really sad part is that they aren't really retrofitting anything hahaha, they are basically saying to the C devs to do wathever they think they should, the rust devs will do their job to keep up with it and all they are asking from the C devs is better communication about the things they are doing. At least that's what that small portion of the conference seemed to be about.

[@CupoChinoMusic]

Developers intentionally making other developers' lives a living hell for job security. Tale as old as time

[@michaeleverson9465]

If the day comes where people don’t need a job to survive they might stop doing that

[@kayakMike1000]

You mean Rust devs making the real devs upset?

[@cyberpunkspike]

If all these degenerates are so competent, then whip up my new OS already, chop fucking chop.

[@cyberpunkspike]

@@kayakMike1000 You meant Rust degenerates, or Rusticles.

[@kirglow4639]

C folks are in the wrong here, but no, they're not doing it for job security - they're just doing it because of their resistance to collaborating with others and learning anything new

[@Sebanisu]

This is like when Congress people Filibuster. The audience keeps talking so the speakers can't.

[@kreuner11]

Congress is both the audience and speakers

[@marcogenovesi8570]

@@kreuner11 they are also the whole circus

[@balsalmalberto8086]

@@marcogenovesi8570 They would be bread too if worse comes to worse.

[@hcolider2817]

Emulating congressmen is not a goal one should ever have lol

[@formes2388]

Filibusters are all about basically timing out a bill and haulting it from being passed - or you basically wait out until the other side has enough people willingly leave that you call a vote and it fails. Why it's allowed is complicated, and has history to it. The simplest form is: Bureaucracy of Democratic regimes are INTENTIONALLY slow, with PLENTY of ways to slow down the process ON PURPOSE, because Tyranny of the Majority is actually a threat to stability in the long term. It's better to have slow, steady change that aims to improve things over time - then over correct, and create radical backlash.

[@LightTheMars]

I had to skip forward through Tso's rant. And it was still longer than I expected. And then he interrupted him with more!

[@Wesfun]

if rust can do it better than the exisiting C code than i dont see why its an issue if rust is in the kernel, linus wants it and people want to support it. I just want a kernel that can be cleanly maintained and not rely on a "this is how we've always done it" mentality.

[@qwesx]

Some people there seem to be done pretending to write good code. If simply documenting what multi-threading stuff may do with its own memory that it passed to another function is too much too ask then the code must be absolutely terrible.

[@haroldcruz8550]

Haven't you just watched the video, all Rust can show for is "memory safety" it sucks on other things related to kernel so no Rust is not in anyway better than existing C code. If Rust brains really want a kernel written in Rust then why don't they make one, than shoveling their language on everyone's throat specially the Linux maintainers that are too busy to waste their time on drama. It's their code base, it's their rule.

[@Rafael-vi4to]

​@haroldcruz8550 haven't you watched the video too? Especially here 11:55

[@alerighi]

Well I see multiple issues. First, it complicates the kernel build process. Of course I'm not talking about x86 PCs, where is mostly standardized, I talk about embedded systems (to which I work on) that have esoteric SOC, if you are luck ARM, that usually compiles a kernel with a ton of patches, that usually require a specific version of the toolchain to build (that is usually shipped by the manufacturer and usually is pretty outdated, I mean years outdated). I fear than on top of all this complexity you ASLO have to manage a Rust toolchain, that by the way evolves more quickly than C thus we must presume that problems would be much bigger than C (while I can pretty much compile a kernel with a GCC of let's say 5 years ago, good luck compiling Rust code with a version of rustc of 5 years ago!). You are adding a build dependency, and a pretty big one! Also, Rust is famous for long build times. Now, a kernel nowadays builds in a couple of minutes, if C is used, but if, let's say, the whole kernel would have been written in Rust? Would probably take more, making development, again especially for who works on embedded systems that have a kernel optimized exactly for that device, more time consuming. Finally, abstraction are never really zero cost. Just adding Rust in the kernel adds footprint, just because you have to add the footprint of all the Rust STD library, or if you choose to not have the STD library at least the various function wrappers to adapt from C and Rust. How much? Probably insignificant for a desktop system that has at least 8Gb or RAM and 1Tb of disk space, significative for an embedded system with 32Mb of RAM and 8Mb of onboard flash memory.

[@mmstick]

@@haroldcruz8550 Did you watch the video? Clearly not.

[@romanstingler435]

I would start using rust bindings and stub drivers where there are the most CVEs in the last few years (networking, Bluetooth, v4l2, AMDGPU has also often CVEs). Improve the supported architectures and add the missing ones. And build the necessary rust infrastructure slowly. Make video calls or conferences with package/distro maintainers and discuss packaging options and versioning. People are missing that the kernel like it is today is the work of over 30 years. Let's see where the kernel could be in the next 5 years if people would just put their egos, biases and stuff like that aside and assume that either side just wants the best for the kernel.

[@theairaccumulator7144]

Those are also some of the most complex parts of the kernel. It turns out, where there is a lot of code there is also a lot of room for errors. Rust wouldn't save them either because it would need piles upon piles of unsafe code to achieve the same functionality, only the top level abstractions would be safe Rust.

[@jonnyso1]

​@@theairaccumulator7144 People keep missing the point on this. Rust isn't about making it impossible to mess things up, its more about encapsulating the problem. Once you get it right, it stays right because everyone using the API downstream don't have a way or need to mess with the more sensitive code. In C you can do something that right now you think won't be a problem, then someone down the line does something in a way you didn't predict and BOM !

[@ShiroAisu10]

@@theairaccumulator7144 You fundamentally don't understand rust.

[@cyberpunkspike]

@@theairaccumulator7144 Yup, the whole concept of "safe" kernel code is bullshit of the highest order.

[@X_Baron]

Torvalds's rule has always been "don't break userspace". Notice how it doesn't mention kernelspace. I gather from T'so's rant that he expects refactoring inside the kernel to break things occasionally, which would require changes in many places. Bringing in Rust would probably force the maintaining of subsystems to be a more collaborative effort. Finding people who are both kernel experts and Rust experts can't be easy.

[@Turalcar]

Breaking the kernel sort of breaks userspace though

[@ukyoize]

​@@TuralcarNot necesarily. Kernel's internal API changes, but external not.

[@Turalcar]

​@@ukyoize A potentially breaking change in internal API can just be checked at every callsite. This, I guess, presents a problem if one of those callsites you don't want to deal with. I expect RFL would be fine if you communicate the new contract to them and they fix it themselves. There are a few problems with that: 1) I don't know why he expects to break things that often - it's not like the file subsystem is new. 2) If I'm asked to fix a bug which turns out to be in a language I'm not fluent in (usually it's Go, Python or Typescript) and I respond with "I don't know this language" or, god forbid, "I don't want to learn this language" I'd be laughed out of the office and rightly so.

[@Acorn_Anomaly]

@@Turalcar about your second point there, regarding being asked about fixing bugs in unknown languages, if this was just a regular general use program, I'd agree with you. But this is about _kernel code,_ as well as having to refine and change function semantics in Rust, which is probably some of the most complicated stuff. Do you _really_ want a novice to a language to be futzing around and making those kind of changes to _kernel code?_

[@kirglow4639]

Rust folks are open to collaboration - that was what they were trying to do in this conversation. Rust folks aren't asking C devs to do anything other than be collaborative and discuss semantics of the C code so that Rust can adapt the best way possible

[@jonnyso1]

The presenter: "We're not trying to force anyone to write Rust and we aren't trying to stop anyone from refactoring code, we're encoding things in Rust the way they are done in C" The emotional dude: "STOP TRYING TO FORCE US TO LEARN THE RUST RELIGION !" That would get very tiring after a while indeed.

[@etherweb6796]

Dude was asking for rust bindings to the C he didn't understand - if he can't understand the C then how will he make bindings?

[@lesto12321]

the big issue is that "emotional guy" is pretty much the sole maintainer of the Filesystem subsystem. Some may be afraid to reprimand him, he is the only one, right? nobody else did step up, right? OR maybe, nobody step up BECAUSE of him.

[@jonnyso1]

​@@etherweb6796 Most people won't, not everything is obvious, that's why documentation exists. I don't think asking for better communication/documentation is too much and above all, is not what the other guy complained about. He was talking as if he was beeing asked to learn and care about Rust and write Rust, which was not the case, its like he went there decided to make his speech and stopped listening entirely.

[@etherweb6796]

@@jonnyso1 Well that is the problem though - the C devs seem to have no problems understanding the C - so what the rust devs are saying is "make the C understandable to me" which is akin to someone asking a physicist to make string theory understandable - at some point if you want to understand string theory you're going to have to learn physics. Same goes for C.

[@romanstingler435]

@@etherweb6796 your argument is misleading. It is like a car. If someone else built it, and you know nothing about cars how would you drive it? You could look some things seem obvious, others can be assumed, but you will never know everything if not someone else explains you a few things. It is not that complicated, but to make it right you have to know all boundaries.

[@burlingk]

The Pro-Rust guy in the video was literally just asking for documentation... Like the barest minimum of documentation. IN C. And the person responded with "I don't want to learn Rust..." When dude was asking for info in C.

[@jamespong6588]

Asking documentation of low level c code is like asking for an essay description of a building instead of architectural drawings

[@burlingk]

@@jamespong6588 No, not really. They were just asking "What input does this function expect and what does it return?" In your metaphor, the diagram is literally what they want.

[@jamespong6588]

@@burlingk meh, not really, you are confusing c++ libraries with classes and tiny generic function names with abstraction and hidden attributes In low level c because everything is in a public scope naming is very long and self explanatory, all you need is in the naming C++ style documentation in c is for function libraries meant to be used by others Not in hundred thousand line low level kernel code doing CPU stuff or hardware /driver stuff, Such in that case, And rust guy was asking not to change bindings\ not documentation Then he moved the goalposts for documentation and ask for permission communication with them

[@burlingk]

@jamespong6588 Scope and openness does not change the fact that a function expects a certain kind of input. It just changes the stakes of giving the wrong input. A function that wants an integer still wants an integer if it doesn't have scope. And, no, goalposts didn't move, the straw men that are erected to attack them did.

[@jamespong6588]

@burlingk guy clearly said, no refactoring of code, then said if you refactor then it's your responsibility to fix what you "broke", then said o just want you to notify us before you refactor, like documentation, Think is linux kernel was never designed to be operated the way Rust wants to operate. And this infuriated the file system people even more than the oversimplified inode code example he provided to make c strawman first. Then the ext4 maintainer said a very deep observation about rust that the presenter totally ignored "We will see if putting such huge semantic information is sustainable" Obviously it isn't

[@velho6298]

I work C Linux drivers daily and I think rust brings many benefits. The interoperability with c and rust in the kernel brings good things such as the stable interfaces, improved lifetimes of existing drivers. I've introduced tooling made in rust in the company and faced very similar issues there from the og c engineers

[@Myname-l3h]

How do you deal with hundreds of rust microdependencies?

[@cyberpunkspike]

Rust sucks, and you don't work w/e lying bullshit you've written.

[@marcusl5605]

@@Myname-l3h you design a rust library specifcally only for linux development, and anything else has to be hand written. It is down to just reject the patches if it contains this nonsense.

[@Myname-l3h]

@@marcusl5605 but in reality maintainers have to put up with lots of dependencies issues

[@Myname-l3h]

@@marcusl5605 they have to patch code all the time

[@TroubledTrooper]

As Linus has said it's an experiment and if it fails we will go back having learned. I agree with him that it hasn't "failed" yet, but if it does no biggie.

[@nobodyimportant7804]

The Rust cult will loudly cry, wail, and moan.

[@maerto]

@@nobodyimportant7804 the only one moaning is you.

[@inconnn]

i mean this is just the C developers complaining that they have to actually explain what their code does so people don't have to read their code to actually figure out what it does.

[@ababcb3005]

Isn't that normal, though? I've had to tinker a bit with the Godot and Chromium codebases in the past and I never found much when it came to how the internal details were documented. I ended up having to figure out where the code I was interested in lived by using a debugger and slowly going through it.

[@inconnn]

@@etherweb6796 oh, i'm sure the rust developers at the rust for linux team can understand C. but it would be much easier if maintainers of the subsystems could tell them how their code behaved so they can reflect that in the rust bindings. or told them if they're going to make breaking changes. they don't even have to know rust or make any contributions! just tell the rust developers what changed so they can reflect that! if you're intelligently designing your code, it shouldn't be that difficult!

[@etherweb6796]

@@inconnn The whole Rust filesystem talk was the Rust guys saying "explain this C for me so I can write rust" so they obviously didn't know it well enough to understand it. If you can't read C code and understand what it does, then you probably don't understand C.

[@inconnn]

@@etherweb6796 their issue with it is that you had to jump through multiple hoops that aren't super clearly defined to properly use the interface. if you just try to use the function, it probably wouldn't behave as you would first expect. with only the type signature of the return type, the rust code very clearly defined what you have to do to properly use the function. additionally, the rust completely won't let you use the value improperly, since it checks. how do they not understand it, if they wrote a clear rust binding around it?

[@zea_64]

@@etherweb6796 The issue is you have complex lifetimes and preconditions that are undocumented. That's an issue for C code too, but the Rust people have to know those details to make good bindings rather than just praying it works like C users of the interfaces would do.

[@untoldhorrordude]

Something that may not have been mentioned is what this situation does to prospective contributors. It doesn't matter if you want to contribute in C or Rust, the fact that there are senior members who stomp new solutions because it threatens them will drive away many people.

[@pkop4]

The happiness, and motivation of senior prolific contributors and maintainers is more important than "prospective" contributors though. If demands of new people held sway over current senior contributors, projects would fall apart and you'd lose your most motivated and productive maintainers who've put in the most work.

[@untoldhorrordude]

@@pkop4 Lets put it like this, a Microsoft employee just quit contributing to Linux due to the interactions with said senior contributors. Who do you think might have the extra few million laying around to create a pure Rust, drop-in replacement OS? Hint: their current net worth is ~3 trillion, they specialize in the OS market, and they have already added Rust to their own kernel successfully. Linux may have just signed their death certificate with this move.

[@FenixFeniks]

@@untoldhorrordude I doubt it. They have their handful barely maintaining all of their current businesses with decades of talent & knowledge shedding catching up to them on top of the monopoly busting suits breathing down their necks.

[@untoldhorrordude]

​@@FenixFeniksI agree that directly making one probably wouldn't happen. I don't know what Microsoft would do; a few ideas, nothing concrete. I do know that Linux is priming themselves to have a competitor replace them with stuff like this.

[@isodoubIet]

Except the "senior member" was 100% correct here.

[@lula4260]

clearly the kernel should just be written in MIPS asm, and statically recompiled whenever you want to run it on anything other than MIPS hardware

[@sergeantsapient]

It's the only way...

[@eldonad]

That is unreasonable, the static recompilation needs tools that will be difficult to maintain, I propose instead we rely on existing and well tested software, and we write the new kernel in pure LLVM IR. I might even accept a small LISP runtime to perform build configuration and testing.

[@Nina-cd2eh]

RISC-V is the architecture of God and so shall the shepherds of divine executables be blessed by its glory, and guided unto the open lands of freedom and eternal holiness.

[@eldonad]

@@lula4260 And god said : "Thou shalt make a new kernel free of sin, and It shall only implement cooperative scheduling, as Jesus said to not do to the others what you wouldn't want be done to you, and thus our holy userspace programs shall never steal the CPU time for their use only."

[@CptJistuce]

This is the way.

[@kfftfuftur]

A dedicated group might be able to reimplement the Linux kernel in rust fairly quickly, but what about the countless number of drivers contained in the Linux kernel?

[@matthewsheeran]

The bottom line is that it is always hard to shoehorn a new technology into an exisitng codebase and that technology needs to be both fully nature and complimentary when you do so.

[@kirglow4639]

It's hard when there are stuck-up people who actively make it difficult for you. It's not being shoehorned, it's being carefully and slowly added while experiencing obstructions at every step from many non-collaborative C folks

[@neeneko]

@@kirglow4639 I also helps when the shoehorning community doesn't treat everything as 'why don't you recognize our greatness! you must be something wrong with _you_'.

[@kirglow4639]

@@neeneko and where do you get that perception? It seems to be a myth perpetuated in C / C++ related forums, but I've never seen this attitude in practice at all. There are people who try Rust and like it more than C and C++ (and hence start using it more), there are people who try Rust and dislike it or don't care for it, and there are people who never try Rust. If people try a language, like it more and start using it doesn't mean they got converted and will start blaming others for not seeing it their way - but it does mean not as many people are using C and C++ as there could've been - hence not as many people in C / C++ forums, which is what causes C / C++ people to become tribal and perceive it as if Rust is a religion and Rust community is the problem. Literally a conflict created out of thin air because of strawmanning and tribalism instead of genuinely trying to understand each other. Believe whatever you want but stop being a dick to others for no actual reason

[@IronicHavoc]

Kind if an oversimplification of this particular situation. The dude in the clip basically threw a temper tantrum about being being forced to "learn rust" when all that was asked for was more detailed documentation on the C code.

[@IronicHavoc]

Like, while Rust isn't mature some of the C maintainers are kinda reactionary about really small stuff too

[@garanceadrosehn9691]

I think we (developers) are in a bad place because a successful operating-system kernel is such a huge project. I'd *like* to see people write new kernels from scratch using a few of the newer modern languages, but that would be such a huge daunting project that no one will be willing to tackle it. That's especially true when you cannot be sure that the project will succeed until you do it.

[@cyberpunkspike]

You sure can, Linux sucks for many things because it has no sane driver architecture like Windows. It has no binary stability whatsoever, because it wasn't designed to make it easy to provide without locking down systems development. Rust just doesn't deliver any of the goods, that's why they don't even bother to try.

[@33KK]

​@@cyberpunkspikeyou're wrong. Just like every other reply you posted under this video.

[@Thorned_Rose]

@@cyberpunkspike Please stop. Every comment I've seen from you here is spouting nonsense. It's nice to contribute but if your contribution is meaningless comments just to engage, that's really unhelpful and just adds more cruft that people have to wade through to get to the comments with actual substance.

[@Aim54Delta]

It's something I have considered doing. I am a stickler for process documentation where I run things, and while I can pick up and use Linux, I won't pretend I have the time to navigate that labyrinth. And windows is deliberately rather opaque. I have considered trying to play with reactOS.... But, again, why reverse engineer a project that has been an ongoing evolution for 40 years? I am mainly interested in developing a lightweight operating system that can securely run communication equipment, phones, navigation equipment, real time situations like vehicles, and which can form the backbone of a integrated systems and instrument solution. That needs file structures and controls, a main program interface, driver handling for various I/O, application programs and monitoring/control... An operating system that allows for third parties to develop programs which can operate on the native or installed hardware. I think if we strip away the expectation to work with existing software and simply create a new operating system kernel to field modern hardware paradigms for modern software paradigms, "it's not that hard." The famous last words of every project, ever....

[@dmitripogosian5084]

And once upon a time one guy went and wrote a kernel singlehanded.

[@steeltormentors]

Read the Linux Kernel Mailing List where Torvalds went ballistic over Kent Overstreet (maintainer of Bcachefs, the Rust dev shown in the video). there's a point where Kent tried to convince Bcachefs is the best file system and Torvalds' response was just absolutely brutal ROFL. Also, take a time to check the Bcachefs performance: slow as hell compared to ext4, btrfs, zfs.

[@lesh4357]

The kernel C code should be well documented, but apparently isn't. It has now been highlighted by the Rust in Kernel project. The Rust devs are only asking for documentation that should have been already there. The C devs don't want to document their code as it adds time and effort to what they do. They don't see the need because of "I know how it works" and "it works now" mentality. Well documented code would improve quality whether Rust or any other language was involved. Whether the extra time involved in documentation costs time is debatable as the rush to code can often end up being slower in the long run. The move to memory safe languages has been endorsed by the White House. The takeaway is that 70% of runtime errors are memory management errors show that this is needed. The argument that it is a "skill issue" is irrelevant, as the "skill Issue" and the memory errors have been around for decades and will never go away without improvement to languages.

[@Acorn_Anomaly]

Documentation is only part of the problem, and it causes another problem if things do get documented: what gets documented gets treated as a contract, a promise, an interface. What happens when that needs to change? The C people need to make a change to the interface, but they can't push the change because that breaks the Rust code, but they don't Rust, so they can't fix the Rust code. The current behavior standard in the kernel is that if you change something that breaks other things, it's on YOU to fix those other things, and make sure things merge well. But again, they don't know Rust, so they can't fix it. So now they have to go bother the Rust people about the change they're trying to make to their own component. Do you think the Rust people are going to like that? So now, the C people are _forced_ to learn Rust, when they've been promised all along that they won't have to. @OMGclueless had a good comment on this, as well: "I don't think people here really appreciate the scope of the problem. The problem is not just that documenting the contract of C functions is hard. It's that adding Rust bindings makes it harder to change those contracts. Here's a simple, concrete example to show what I mean: Suppose I write a simple C API consisting of two functions, "new_frobnar" that takes a pointer and returns a heap-allocated struct that contains that pointer, and "delete_frobnar" that deletes that heap allocation and leaves the pointer it contains up to you. The natural Rust binding for such a type is some "linux::Frobnar" type that contains a mutable borrow (whose lifetime therefore matches the lifetime of the containing object). Now suppose I want to add a "reset_frobnar" function that switches out the pointer contained in an existing object, is this safe? In C the answer is obviously, "Yes", because no one calls the function yet so it's obviously safe, and anyone who wanted to call the function would have the responsibility of making sure that the lifetime of the old and new contained pointer were handled correctly. And yet the Rust binding is obviously wrong now because the lifetime of the contained pointer and the lifetime of the object itself are no longer tied together, which means the Rust borrow needs its own independent lifetime, which means a bunch of function signatures in Rust need a new lifetime bound, and so on. This could be quite a big change, and not one that someone who only knows C is capable of making. Just to add a "reset_frobnar" function to the codebase. I hope you can see why a C library maintainer would not want to be beholden to supporting Rust bindings in this case."

[@rezah336]

if the white house wants it, then it is not good

[@meandyours]

@@Acorn_Anomaly > So now they have to go bother the Rust people about the change they're trying to make to their own component. Do you think the Rust people are going to like that? isn't that already what the rust people are signing up for when they got involved? why is this a problem?

[@amorphousblob2721]

@@Acorn_Anomaly "But all they're asking for is documentation, so the C devs just want to have undocumented code!" The Rust guys seem to be counting on C devs not being aware of such cases until after they extract a commitment to support Rust bindings from them. @meandyours, what happens when the Rust people refuse to fix their code to accommodate a change from a C developer? Does the change simply become unmergeable? That would give the Rust people veto power over anything a C dev does.

[@Ruhrpottpatriot]

@@amorphousblob2721 > That would give the Rust people veto power over anything a C dev does. How about doing it like any sane company does it when changes to ICDs and contracts are in order: Look at both sides and decide which party has the better arguments and then follow that. Because I can turn your argument on it's head and state "What happens when the C people decide to not change a thing, even if this results in sub-par (or vulnerable) code on the Rust side. That would give C people the power over anything a Rust dev does" > So now they have to go bother the Rust people about the change they're trying to make to their own component. And that's bad how?

[@bitwize]

No. Ted Ts'o was being an asshole. Linux has been shit at documentation for decades; understanding how to interoperate with a given piece of code usually entails reading the code and figuring it all out yourself. The Rust devs are just flagging up lazy cowboy-coder bullshit that's been plaguing the kernel for a long time. Look at any BSD, you will find code that's not only easier to read, it's so well documented you can write a new driver just by reading the man pages. Linux needs to fix its shit, and it looks like it falls to the Rust team to shed light on the issue, because the old kernel guard is mainly the kind of C grognard Rust was created specifically to replace.

[@KasasagiWad3]

documenting what happens INSIDE a function is frowned upon for good reasons, coders will inevitably write what they BELIEVE the code should do, not what the code actually WILL do in a corner case which likely isn't even memory related. the only place which absolutely NEEDS documentation is the inputs and outputs of a given function, here there's room for improvement.

[@alistairwillock7266]

@@KasasagiWad3 The problem here is _exactly_ that how the inputs and outputs of a given (kernel C) function are documented is currently insufficient, because the input/output lifetime information is (often) missing. The C kernel developer position - as articulated by Ted T'so - is that you shouldn't be attempting to encode lifetime information in a function signature, because that's _"too fragile"_ and imposes too much of a burden on the maintainer. The Rust developers' position is: _"Hey, it's 2024, and you can't do memory-safe development without explicitly defining that contract."_ ... And they're not wrong. The disconnect is that the legacy C developers have been writing code for 30-plus years without being forced to incrementally capture that information, while the Rust developers are working in an ecosystem that _forces_ you to explicitly define those contracts at all times. Figuring out how to bridge _that_ divide is proving to be _really_ painful. One anecdotal report covered during this vlog that I found really concerning, is the statement by a Rust developer that bug fixes in C kernel code for memory safety issues that Rust devs identify are often being rejected by maintainers. If that's really the case, then Linus probably needs to weigh in on that issue pretty heavily.

[@thewhitefalcon8539]

Then the rust people should make their own kernel

[@OMGclueless]

​@@alistairwillock7266 I strongly suspect that the "memory safety issues" identified by Rust devs are rejected not because the kernel maintainers are happy to live with memory safety issues, it's that they don't consider it a memory safety issue unless it's actually exhibited by real kernel code that's been merged to the tree. E.g. a bug report of the form, "If you make these C function calls in ways that appear consistent with the documented behavior of those functions, memory unsafety results" is met with the response, "So don't make those C function calls. We have the appropriate controls in place already to make sure that drivers that make those calls won't get merged." People trying to make Rust bindings are trying to write them such that _any_ safe Rust code that type-checks and borrow-checks will not exhibit unsafety. But the set of safe Rust programs using those APIs is infinite, and it might be the case that proving memory safety for that infinite set of potential programs has more cost than manually enforcing memory safety for the finite set of driver programs that is actually merged into the Linux source tree through code review and testing. That's the steel-man argument for why the Linux maintainers' position is what it is.

[@SuperSmashDolls]

@@OMGclueless If it's just a matter of not calling into C a certain way, Rust can wrap C types up in a way that makes it impossible to do that in safe Rust, and really obvious not to do that in unsafe Rust. That's not the problem. The problem is that we don't know what set of C calls are valid, because there's nothing documented to say "Oh, don't call these functions this way", and the maintainers DON'T WANT to write that documentation because they think it means either no more refactors or only Rust people can refactor.

[@krelsen7]

i paused on the first frame of this video and it's pure nightmare fuel. blurry Brodie can't hurt you. blurry Brodie:

[@blurrybrodie]

it's me. blurry brodie. i am here to hurt you.

[@yusefaslam9675]

ah crap he's found you

[@krelsen7]

@@yusefaslam9675 shhh be quiet, he reacts to sound

[@Cool-Game-Dev]

No way someone made a account for that lol

[@LuizDahoraavida]

Rust really is close to a religion from my experience

[@bariole]

For people thinking that C developers in video are lazy while Rust developers are reasonable - what Rust developers are here asking for is a stable interface, or in C jargon ABI ("... we want known semantics"). And Linux will not and can not give that to anybody. Linux does not have a concept of a standardized interface. The hole point of not having stable abi is to force integration on a source code level. It is design choice older than Rust. This intentional choice was designed and promoted by Linus Torvalds itself since earliest days of Linux. Rust developers could solve their problems by writing their own binding in C as a bridge to a Rust code.. And the C developer literally said that (".. no.. it is YOUR obligation..."). But Rust developers don't see writing and maintaining C code as "fun"..

[@oliverherzog7702]

They ask for documented ABI, they don't ask for it to be stable. They ask it to be able to understanding the change. In all effect ABI changes should be reasoned on and documented so the pro of an api changes against the previous ABI is clearly understandable if the maintainer dies of old age or heart attack because he had to read rust code or anything els than c/phyton/asm.

[@Gin2761]

C people calling Rust a religion while defending C as a religion.

[@NoNameAtAll2]

2 religions fight each other

[@sturdyfool103]

@@NoNameAtAll2the holy war has begun

[@tommybronze3451]

yeah but C is a religion and rust is a cult

[@iridium1118]

Typical C dev is mad that they have to adopt modern good programming practices

[@RustIsWinning]

​@@tommybronze3451not a cult 🦀

[@TheSolidSnakeOil]

This is why I think linux is screwed after Linus is gone ( knock on wood). You don't see programmers hanging on in projects very long. Mostly they hang around a few years and want to move onto something else. They just don't make em like they used to.

[@cjcox]

This is a problem in general. Rust today, "next greatest thing", tomorrow. Many zealots just don't have the long term commitment to see things through. We'll see... in short, everything flows to the lowest "common denominator"... hello, "C". With that said, the "old", have seen many many many a "great thing" that has come and gone. And some were really great! But, they are also, gone.

[@johnc3403]

He needs to promote a lot of promising Rust dev's to his inner circle and retire out a lot of old C dinosaurs.

[@CptJistuce]

​@@johnc3403Or maybe something more mature, like Go.

[@cyberpunkspike]

@@johnc3403 You haven't delivered jack shit, Rust isn't a productive launguge.

[@mmstick]

@@cyberpunkspike You haven't delivered anything in Rust. It's the most loved programming language on Stack Overflow for 8 consecutive years now. Productivity is the most commonly-cited reason for loving Rust.

[@b3stbuddy]

What I hear the rust people saying is, my new thing won’t work correctly unless you give me information I don’t have, else my thing won’t work. This sounds incredibly selfish to me. Your new shiny object doesn’t translate to someone taking on more work.

[@username7763]

To work effectively on a project with C and Rust, everyone really does need to know C and Rust. It is like how some projects like to split "front-end" and "back-end" developers. Some of the dumbest things happen from that, you have to know how the system as a whole works. Yes, if there is going to be Rust in the kernel, the kernel devs need to know at least the basics of Rust. They don't have to be experts, or like it, but they do have to know it. But I totally get that it is a community effort with volunteers and the additional burden of this may be too large.

[@MrKlarthums]

It seems like Rust wants very precise documentation to match its semantics. The C methods are underspecified from the Rust perspective and it's a pain for the C maintainers to make documentation guarantees when your language can't enforce the guarantees it claims. Not to mention pushing back features because this takes significant work.

[@amorphousblob2721]

Not to mention that the C code is probably doing things that Rust wouldn't allow (such as having more than one mutable reference to a value), and therefore it would be impossible to encode those things as Rust declarations. The Rust guys would demand that these practices be changed.

[@yearswriter]

@@amorphousblob2721 not at the interface lvl? Rust wants to encapsulate unsafe and it can handle unsafe code in the unsafe code parts - so I am not sure I get this comment. I am stupid though, and have very bad understanding of both rust and C, let alone kernel C and rust, where code can break between compiler implementations. The 19:32 post is very interesting to read through and more or less adequate as far as human interactions go

[@widget5963]

@@amorphousblob2721 AFAIK Rust allows more or less anything C would as long as it's in an `unsafe` block. Rust (as a language) wants to make it clear when you're pulling shenanigans that it can't validate, so that devs have a good first guess as to what's causing crashes. In this case, what the rust devs are asking the C devs is things like "can I assume you won't overwrite my memory that I'm giving you a pointer to?" and "does a negative return value mean that the function failed?" These are things that should generally be documented anyway. No one's trying to replace C code with rust. Let me repeat: no one's trying to replace C code with rust. They just want their own parts of the kernel to be able to rely on the existing behavior elsewhere in the kernel. And then because rust makes stronger guarantees, to fix the many bugs that they'll end up finding in the existing C code. And if you're mad that people are using static analysis tools (the rust compiler) to find bugs in your C code, maybe you shouldn't be in charge of it?

[@amorphousblob2721]

​@@widget5963 The author of "actix-web" tried using "unsafe" to get around Rust's bullshit, and the community got their pitchforks out. He eventually was forced to rewrite the "unsafe" sections in "safe" Rust, incurring a performance hit in the process. That's what happens when you write an "unsafe" block: The cultists go apeshit.

[@mkabilly]

​@@amorphousblob2721 which is what you can see in that dev talking about gpu drivers' comment. They tried encoding something in Rust, it didn't work as well, they requested changes be made to the underlying API (even claiming the underlying API didn't make sense from all perspectives) -- might've made the changes themself and opened a PR, idc -- the maintainer was like "this is stable, do what the other driver does", and then the person gets mad and blames the maintainer. idk, I'm annoyed at this whole thing because, as much as they'd like to pretend they're not, Rust developers _are_ expecting extra work from C devs so that Rust fits into the kernel while they're either doing completely unpaid labor or need to work on whatever management wants them to. And the C devs might just not be as interested on Rust, either in the kernel or in general. It is kinda unreasonable to expect a C FS dev to know Rust enough so that no refactorings of theirs break the Rust wrapper.

[@jongeduard]

Rust for memory safe 🦀, but it's not drama safe. 🤪

[@Myname-l3h]

Or microdependencies safe😊

[@Krmpfpks]

It certainly isn’t 😂

[@mgbertiaux]

"Memory safe": If you heard the explanation, you should notice that "memory safe" is a lie. Rust works "well" (lie too), running OVER an OS, who manages resources like memory. Some unallocated or deallocated memory can trigger unseen failures because Rust is waiting for Kernel responses, but these responses will never happen because the code is being executed below/under/behind the OS's memory management. As a result, no failure messages, codes, or alerts will be received. In Windows (Microsoft), the most iconic screen is the "Blue Screen of Death" (BSOD). It will be trigged when the Kernel detects actions like writing to memory sectors outside of allocated space, among other things. However, the BSOD is designed to "catch" issues that Microsoft developers either can't or don't-want-to handle. If you do something that the Kernel cannot catch, your PC or device will likely shut down or restart. The "unseen" errors from Rust can bypass/skip "the BSOD" (or "Kernel Panic" in Linux) and cause instant shutdowns and restarts, which can potentially damage your hardware depending on the nature of the failure.

[@oracleoftroy]

To be honest, I'm surprised Linus even entertained the idea of Rust in the kernel. C++ enthusiasts tried to bring the increased safety and usability that C++ offers over C to the kernel decades ago, and he blew up in an irrational rant and outright refused. The Linux project has a culture that reflects its creator, and now that Rust is trying to bring similar benefits, it doesn't surprise me that the same kind of resistance still plays a huge role. I wonder if revisiting C++ in the kernel would be a more acceptable compromise now that other big name projects, especially GCC, have adopted it. Even just using the stronger type system to encode lifetimes and error conditions would go a long way to help make the kernel more self-documenting, even if they otherwise keep a mostly C-style. There is an advantage that C++ speaks C natively, whereas Rust always has to go through bindings that have to be separately maintained.

[@pelor92]

I think this is the perfect storm that will blow up in everyone's face, and I fear there will not be any positive conclusions. Both sides make good points ON THE RUST SIDE Having some formally defined and clearly documented bindings for internal APIs would be great, both for security and for onboarding new developers, also Rust higher abstraction level could really simplify large, non critical portions of the kernel (configurations, non hot-path setup and initializations, etc.) ON THE KERNEL SIDE If we take a long term view (as we should), the "NEVER BREAK USERSPACE" sacred rule couples together rust and C extremely tightly. As soon as the first rust based driver gets shipped by someone, all the rust interfaces, bindings and API become sacred as well, as such any ipotetical C developer wanting to restructure some part of the kernel (think memory management, RCU, etc.) will be either forced to learn enough of rust to avoid userspace breaking, or wait/beg/find for someone with rust knowledge to do it for them. Now, I highly doubt that with any other language you would get this sort of pushback, since most experienced maintainers could probably pick up the language extremely easily however rust has a notoriously steep learning curve (a la haskell), and learning it is a commitment that Is probably unreasonable to ask to most high level maintainers. What I also think does not help in the slightest is that I am convinced (as I suspect most kernel maintainers are) that to do a good job in a mixed language environment, who has the power of deciding/advising/vetoing what goes in or stays out of a release (not just Linus, but all subsystem maintainers) need to be at least proficient enought with rust to understand what the language does, and here we go back to the previous point of the extemely steep learning curve (which I feel is probably point of pride for rust developers, and not something to be addressed) Probably the main fear (I am speculating here so I MIGHT BE WRONG) of many core developers that are against rust in kernel is that without a large sponsor committed to getting rust support into shape and with pockets deep enough to support it; is that if the rust hype dies down, and the language fizzles out (I don't think it will, but it is a possiblity) in the medium term (lets say the next 5/10 years) they are left with a buch of code in a language nobody of them knows, that is difficult to find people experienced in, with userspace depending on it. Also there are many instances, deep in the kernel where the lifetime requirements/semantics the rust developers require for their bindings are unclear/not possible to know a priori because the hardware itself can do wierd and wacky things, either because of bugs or because of design decisions, thus what the rust people are asking is probably not a trivial effort) CONCLUSION The only way to solve this issue is probably for both sides to step down from the barricades and realize that both have good point and start working together -C developers need to stop with the machismo and start accepting that C has its flaws, and we might want to put some guard rails on to avoid the many, many footguns -Rust developers need to realize that they are asking the C team a gargantuan effort both intellectually (figuring out the semantics they want is not a trivial task in a codebase as large and as complex as the kernel) and practically, as I suspect it will requre several massive refactorings of core systems, to get the C to meaninfully comply with the guarantees required by rust (making everything an unsafe mutable reference kind of defeats the point of using rust in the first place). Thus pushback is going to happen, as effort and time are resources that somebody other than them will have to spend (either in term of personal free time, or money, or company time/political capital )

[@commonsay4191]

This is the most pretentious shit I've read all day. The answer is a total rewrite to accomodate the new paradigm. You don't need to fit a square in a circle-shaped hole.

[@pelor92]

@@commonsay4191 Suggesting, or even thinking that a complete rewrite of a project as large and complex as the Linux kernel beyond stupid… It would literally cost billions of dollars requiring tens of thousands of man hours of raw coding and probably millions of hours of verification to get to the same point Linux is today. While C might be an old language with its flaws, the kernel is currently deployed in production on billion of Devices, from the depths of the oceans up to other planets, and it basically underpins the global economy. And no programming language past present or future can replace that (quickly )

[@commonsay4191]

@@pelor92 "Oh no, I can't do that! It'll take too much money and time, I have to do the same thing instead to an existing project so I can spend even more money and time, AND piss off my peers"

[@tablettablete186]

Me as a Rust dev: oh no! Also me: more FOSS drama! Let's goo!

[@gljames24]

🍿🍿🍿

[@cyberpunkspike]

Shocking, the Rust community celebrates whatever drama they cause. You're degenerate, and so is your horrible language.

[@AchmadBadra]

FOSS is just bunch of dramas, not only on developments, backers, users, community, companies, governments, fanatic fanboys, even unrelated to development one. Is already ridiculous. No wonder linux still less than 4% on desktop segments, on mobile segments is already monopolize by companies not by linux itself is kind of ironic. Just abandoned those drama, and focused on standardization without complaining "why our FOSS solutions is not become industrial standards", like on libre office drama or "why you complaining and quiting the project? " after disastrous demand from users on free software without warranty or fork mentality everywhere.

[@NoxiousNinja]

"If I make a change, I will fix all of the C code" is such hubris. If you have 50 filesystems using ypur APIs, what are the chances you're going to update all of them correctly all of the time? What are the chances that someone who _doesn't_ have a decade of experience with the subsystem would be able to do that? Leveraging the type system may make your refactoring more annoying, but it makes it way safer, and Linux isn't some hobbyist project.

[@kirglow4639]

100% based take. It's so sad that because of this stupid resistance, instead of thinking critically about the codebase improvements that can and should be made, the discussion now revolves around Rust. NO! Rust made you finally think about the giant mess of the fragile codebase that doesn't have clear semantics and instead of admitting it and trying to improve it, you resist and call Rust "religion". Completely pathetic

[@PhthaloJohnson]

@@kirglow4639 Unfortunately, you will find both in industry but also in open source that some people don't develop things because they care about the final product, they do it to satisfy an ego itch that gives them a sense of power, superiority and competency. To those people, critique is unacceptable. Documenting the code and teaching others how it works makes them feel threatened and out of control because their baby is taken away.

[@christianbarnay2499]

@@kirglow4639 Exactly. This not about Rust at all. It's all about some power hungry dude going on an ego trip because he's seeing a threat to his personal power. When he talks about cult he's actually projecting his own desire to be at the center of everything on other people. That close minded toxic attitude has no place in a collaborative project.

[@dansanger5340]

As the lines of code become battle lines, everyone is a player in this grand drama. Who will come out on top? Who will be left behind? And who will find their name etched into the annals of Linux history? Find out on the next episode of 'As the Kernel Turns."

[@kuhluhOG]

Fun fact: Kent Overstreet, the guy who gave that presentation where he was strongly interrupted, is the same person who also develops bcachefs.

[@Herr_U]

This entire Rust vs C discussion is giving me harsh Ada vs C flashbacks...

[@Ooga658]

That guy sounded like he was about to burst into tears when he totally misconstrued what they were saying as "I'm being forced to learn rust" lmaooooo

[@IvanKleshnin]

He's right though... Now they learn Rust, and in 3 years Linux team decides that Zig is the way to go. Another kernel rewrite? 🤡

[@pedrocx486]

@@IvanKleshninDid you pull this argument from your behind?

[@IvanKleshnin]

@@pedrocx486 Rust gentlemen checking in

[@HUEHUEUHEPony]

Sad day for transphobic people

[@HksjJkdkd]

​@@IvanKleshnin there is no reason to use zig its also memory unsafe its just a modern C with its disadvantages

[@cinemint]

Honestly I think there should be an entirely different kernel written in Rust. Leave the C kernel in C.

[@neeneko]

But they don't want to write their own.. they want to shape something existing, prove they are better than the existing people, and be the future.

[@htpkey]

​@@neeneko You must be aware that all your comments are reactionary, right?

[@LackofFaithify]

@@neeneko Want to. Heh. If they really wanted to be the hot new things on the block, they would have done that already to show up the people in the old folks home, ending all debate.

[@Coopertronics]

God bless Dennis Ritchie.

[@stefanalecu9532]

Why God bless him? He should've chosen Pascal instead ;)

[@CptJistuce]

​@stefanalecu9532 Pascal had limitations that made it undesirable at the time, if I recall.

[@unclesmrgol]

@@stefanalecu9532 Wurthian languages don't seem to last very long.

[@dealloc]

I understand both sides of the discussion; encoding semantics through a type system has its tradeoffs; while it would help with providing context to consumers, it also makes it difficult for maintainers to change semantics. This is something any developer will have to face when building APIs in general; provide enough rigidity that it doesn't fall flat on its nose, but also allow semantics to change organically without requiring major refactors; like extending its use cases that would require changing the types, and therefore break everything that relied on those semantics. I am a proponent of Rust in general, but I also acknowledge that there are downsides to it, especially around coloring of structures, traits and functions through types. It does make it more cumbersome to introduce changes without having to change everything or deprecate and introduce larger surface area. While C is definitely too flexible (i.e. relying on casting void pointers), Rust is also too rigid in my opinion. Finding the middle-ground is really difficult because they are so far from each other on the spectrum. As Brady says, this needs to be a civil discussion between the two parties; and non-constructive rants of "you're doing it wrong, and I am not going to budge".

[@morglod]

Interesting thing - every time some rust fans appears, every time there are drama, stupid claims and skipping critics (on rust side) That not happening with other languages

[@solidhyrax]

It happens in other languages but in a smaller scale. I'll let you have a guess on what rust developers have in abundance compared to other languages.

[@morglod]

@@solidhyrax they have a lot of school homework

[@solidhyrax]

@@morglod not quite there, but you're on the right track. I will not disclose to answer, but you should ruminate on it by yourself.

[@morglod]

@@solidhyrax Mr. Riddler

[@matthias2447]

Ah yeah, here we go again: another weekly drama in the Linux space. Last week it was bcachefs, this week it is Rust. What will it be next week? Hmpf...

[@BenjaminWheeler0510]

Betting on gnome drama

[@user78405]

vaxry returns with bigger team behind him/her...LINUX IS DOA and DOOMED

[@Zoverone]

I think we all know who he is, the drama queen.

[@dashcharger24]

@@matthias2447 It's the world nowadays.

[@NatesRandomVideo]

bcachefs was a symptom of the overall rust kernel acceptance process - same problem new week

[@navi93243]

Paraphrasing John Carmack: "when you start mixing languages in a project... That is a mistake"

[@Marco-pz5dx]

My understanding is that the problem is not C vs Rust. As others pointed out, the issue lies in C signatures often lacking the appropriate semantics and documentation that would, while not ensuring, at least ease correct usage. Now, though, for the hot take, the answer for a huge code base like the linux kernel should not be IMO introducing a whole new language. I do honestly believe C, too, has ways to enforce correctness, potentially even paying some runtime penalty where it makes sense (even in DEBUG builds only), the fact it is not done, is that perhaps this is not seen too valuable as refactorings are frequent (and this just adds more code to be maintained and reviewed). It is also quite tedious work and perhaps, there is simply too much legacy code that nobody really wants to spend proper time fully understanding, documenting and introducing bits of type safety, assertions and documentation (all of this can also get quite verbose, opinionated and consequently raise more than a few eyebrows). In the end this may be seen as a lot of effort (as it would likely lead to some rather large refactoring) over something that "just works". All that Rust does, IMO, is encouraging such coding style and offering a preset of opinionated abstractions everyone can more easily conform too, it, however, also actively discourages low level memory manipulations (as the compiler does not really have a clue whether it's safe or not to do them, requiring for e.g. use of "unsafe" in many places) ending up perhaps too opinionated / obstructive in some areas (which is honestly OK for most of application development, but probably not so much for kernel dev). TLDR: Safe abstractions can be created in C without resorting to Rust, but it's grunt work, and adds effort for maintainers, so it is actively avoided, despite benefits in cleaning up the API and asserting invariants throughout the code.

[@LackofFaithify]

Silence with your reasonable idea. But yeah, when you have something like this, the first thing you want to do is see if you can streamline/update it in regard to itself. IF that is not feasible, then you begin parallel work on the replacement. Never in the history of ever has attempting to force graft/retrofit something brand new and untested for all actual purposes into a functional (if inefficient, etc..) system ever turned out well. It starts the factional fighting amongst the people and the breaking of the new, worse system that has all of the drawbacks of both plus new drawbacks due to the unknown issues that always arise from this sort of hybridization and less of the benefits of each if they were on their own.

[@maxbd2618]

Alright I have an idea, let's just rewrite the entire thing in Zig

[@chrism3790]

Honestly, semantic information about function signatures should be a standard part of the documentation, Rust or no Rust. It's pretty entitled to shit on Rust devs because you refuse to acknowledge you could have done a better job documenting your own work...

[@dmitripogosian5084]

They do not need to use your shit. They can go away and start their own project

[@mkabilly]

The sheer entitlement of expecting a dev to do the extra work of keeping separate in-depth documentation of their work for free because you wanted to use a hip language... Talk about expecting free labor from volunteer workers because you don't want to do it yourself.

[@chrism3790]

@@mkabilly The world runs on linux. Impeccable documentation should be a minimum requirement, hip language or not.

[@mkabilly]

@@chrism3790 the world also runs on windows, MS is even paid for it. And I can tell you it has nothing close to “impeccable” documentation. Does the software in production in your work have it? Do you know any that does? Do you write impeccable documentation for your code? Not even userland POSIX doc is impeccable. Why do you assume the devs have to maintain impeccable docs? Do you think Linux would have gotten anywhere close to what it is if there was an expectation that everything in a release was impeccably documented?

[@chrism3790]

@@mkabilly I don't write perfect code and nobody does. That's not what I'm talking about. I'm talking about the reaction, and the resistance to change. "Everybody is scrappy, so I'm not changing either" should not be the attitude when what we're talking about is software that runs on Airplanes, satellites, data centers, and virtually every server on Earth. How about "yeah, maybe we should do better"?

[@HickoryDickory86]

All I heard was the Rust developers just asking for i fo on the C syntax so they can write the Rust code to match, and then all the C devs just lost their s××t for the Rust devs daring to exist. It's really childish behavior on the part of the C devs, really. I just can't see it any other way. A lot of what they're arguing is nonsensical; literally no one is demanding that they learn and use Rust.

[@davidjameswales]

It's not quite that simple. A lot of rust developers have never done anything like kernel development, what about when the rust implementation has a rust only issue and the guy who has 30 years of understanding how it all works together has retired? Just one example of many. These things happen all the time at companies, there's nothing stopping them from being an issue here.

[@Nina-cd2eh]

@@davidjameswales Most Linux contributors have never done anything like kernel development. That's not a good argument. One of the things this presentation tried to show, is how the Rust type system is better at describing requirements. This is an objectively good thing that will allow people to contribute without needing this imaginary "guy who has 30 years of understanding". It's explicit, it's verbose, it's easy to read, and that's exactly why it will be more maintainable even by new kernel devs. What you're complaining about is exactly the issue Rust aims to solve in the codebase.

[@cyberpunkspike]

@@Nina-cd2eh No, embedded that much semantics in the type system is brittle, fragile, and detrimental. That's why Rust codebases are horrible to work in. We wouldn't want to avoid Rust if it made our lives better.

[@experimentalcyborg]

@@davidjameswales Kernel development isn't some kind of separate thing, it's just systems software development. The whole reason Linux kernel development is infamous is because it's so idiosyncratic and poorly documented. Instead of accepting that as a feature of the Linux kernel, many people want to fix that - but that's hurting some egos along the way. It shouldn't HAVE to be arcane magic, but some people are incentivized to keep it that way because they don't want anyone else to touch their little kingdom within the Linux kernel.

[@Nina-cd2eh]

@@cyberpunkspike Ah yes, brittleness. Because nothing can compare to the steadfastness and reliability of undocumented void pointers, and joy when playing "Where's Free()?" during gdb fridays. Sometimes I wonder if you people ever touched a computer in your lives, much less know basic Rust or C development. You're just saying things with no substance. It's fine, you don't understand the concerns large codebases have. At least try and learn from people that know better and are responsible for making those decisions. You pretending you know better than Linus himself on the suitability of Rust for example, is certainly... something. Linus himself, and Google's research has already debunked anything you've said here. In other words "skill issue". Learn your tools.

[@krux02]

As a developer who once got his work ported to rust, without asking, I totally understand the backlash on Rust. The code that I wrote I knew how to deal with. The rust code was much more complicated, with many types that I had no idea what they were supposed to mean. It completely blocked me from doing anything with that code, simply because it was rust now. Rust fans often forget that they are pushing a lot of complexity onto other developers. If I would be a maintainer of Linux, I wouldn't want rust code either. People love change (if they are the ones proposing it).

[@Nina-cd2eh]

Nobody is rewriting anyone's anything. Rust devs just want to _add_ things and contribute, and these ideologues complain, because they have an ontological hatred towards Rust. Nobody is trying to rug-pull anyone. That's not a real thing.

[@Spartan322]

@@Nina-cd2eh But Rust demands semantic knowledge, it gets pretty useless without that, (not really unique to Rust, but it is the most aggressive language I know on that) and the burden of that semantic knowledge is on the C code which the Rust devs either have to refactor or ignore, the latter of which means they have no advantage to that code. (or worse, it makes false promises and then the Rust code is more broken then the C code was) In which case how exactly is Rust advantageous for that case?

[@cyberpunkspike]

Change for its own sake is degenerate, and Rust is overly complex, while making code bases which are brittle and fragile.

[@cyberpunkspike]

@@Spartan322 It's not, Rust benefits nobody but the cult of Rust. Fuck these degens.

[@mmstick]

Things that never happened.

[@Problematist]

17:44 As for Android, their IPC implementation Binder, is being ported to Rust. The C driver is very complex and even a simple refactor introduced security vulnerabilities. Alice Ryhl had a good conference talk on it.

[@Azureskies01]

I have no idea how linux works, not an expert or even a novice however I will say if something is better than the "standard" it needs to be self evident. If it is not then you will have a hard time convincing people to stop or change how or what they are doing. Even if it is there *will* be push back but the push back will be drowned out. To me, after watching this whole video, sounds like Rust is a nonstarter.

[@kjeldgaard0]

I can't say I understand these problems fully, but if it has to do with C interfaces evolving or being changed, and the maintainers don't want to be bothered with how that affects the Rust bindings, it seems to me that there ought to be a way to solve this technically. For example via some kind of subscriber system where subscribers to a particular API gets advised automatically that things have changed. Linus solved the problems of managing thousands of patches from thousands of people by inventing git. Something similar could be done administering the function signatures.

[@applecastaway4256]

will we see windows completing the rust transition before linux

[@noilfaund]

NEVER negotiate with Rust developers.

[@axalius572]

Rust support in the kernel is nowhere near ready. The APIs are either non-existent or not finalized and most of the online documentation is incorrect.

[@ITSecNEO]

And why? 😂 because of ignorant C devs xD Annoying Boomers everywhere in the Linux kernel

[@michaelbuckers]

@@ITSecNEO >rust implementation is broken >it's c's fault

[@coffee-is-power]

Even i started my own linux-compatible rust kernel some days ago I'm going to release the source code once i think it's ready

[@sturdyfool103]

There are few failures as a programmer as large as refusing to learn, and another is: refusing to cooperate with the other teams in your project, the C side of the argument is clearly committing both sins at the same time, all while trying to complain about being forced to learn Rust and making emotional arguments

[@Myname-l3h]

But why should they learn some random language? Write the kernel in java!

[@bankbank]

python imo

[@bountyjedi]

obligatory brainfuck comment

[@cyberpunkspike]

@@Myname-l3h Good point, fuck these rust degenerates, they have no right to impose shit.

[@brettfo]

@@Myname-l3h If you want your sarcasm to be taken seriously, you would have suggested a language that doesn't run in a VM.

[@Purely_Andy]

13:25 why does it look like your cursor is trying to log in and you're fighting it?

[@SteinGauslaaStrindhaug]

😂

[@MikkoRantalainen]

I like both C and Rust and even though I think that writing C code is "easier" than writing Rust (may be a skill issue on my part still) I have to honestly say that writing perfect C code is next to impossible. I think we can all agree that Linux kernel developers are close to most being most skilled C developers in the world. And look at the results: those top of the top developers writing C code that is publicly reviewed on LKML before being accepted in the kernel and we still end up with all kinds of CVEs. If these people are still not skilled enough to even avoid security bugs with C, maybe C is not a good solution in long run. Will the parts written in Rust ever have CVEs? Probably yes, but that will be much much much more rare event than with C. And such CVE would highly probably be about logic errors, not about memory corruption or about thread safety, unlike with CVEs dealing with code written in C. Yes, slowly switching to Rust in Linux kernel would require nearly all kernel developers to learn both C and Rust. I don't consider that too high minimum bar to join kernel developer community. The level of C understanding you currently need is pretty high already and Rust isn't that hard a language to learn if you really put some effort to learn it. That said, I totally understand that NIMBY effect works for software development, too. All the greybeards that have made an entire career with Linux and dealing only with C code will not be happy to hear that their system wouldn't be good enough and that they would need to learn to do something else. In the end, the important question will be "what's acceptable" when it comes to code quality and performance. If writing stuff with Rust is 10x harder, is it worth it if it can cut 90% of all the yearly security bugs? What about if it can cut only 20% of all the bugs?

[@mSparks43]

As long as rust devs wont use C, and C devs wont use rust, I dont see how the two communities can coexist in a monolithic kernel. Rust devs can now write kernel modules in rust, thats about where the story ends?

[@abarratt8869]

If Rust ends up dominating the industry, projects with large slices of C code will die for want of volunteer expertise. Linux already has problems getting volunteers, and it’s getting worse. Betting against Rust is dangerous because if it does win you’d need to have converted the entire code base before the last C developer checks out and the C code becomes unmaintainable. In a sense no one knows if Rust wins. One way of being certain is to make it happen by joining in. C today is in the same position as assembler was. As soon as C became viable we all dropped assembler. No one looks back on that as a bad thing. C too now has an up and coming rival, and history indicates that the better solution wins. C isn’t the better solution.

[@mSparks43]

rust adoption isnt even on par with fortran or cobol yet, let alone its main competitors like java or python. Very long way to go before it comes close to C/C++

[@abarratt8869]

@@mSparks43 yes there’s a large installed code base in other languages. That in no way prevents such languages going out of fashion and becoming difficult to find devs for. The trick for any code base that the owners want to persist is to rewrite it in the next best language before no one’s left who understands the old language. MS themselves have been pretty proactive in this; MS Office and Visual Studio used to be written in C++. Now they’ve all been rewritten in C#. I think this is why they have their odd CPP/CLR language which builds .net binaries from C++ code; using it you can slowly convert a code base from C++ to C#. I dare say that if they could rewrite the NT kernel in C# they would, except C# isn’t a system language. That’s why they’re using Rust for that job.

[@Krmpfpks]

First: I love rust as a language, I bet my company on it. It helps us make safe server code that can be easily reviewed for security. If it’s safe rust, it’s memory safe. If it’s marked with unsafe (rarely) you have to double and triple check by an experienced developer. This would be a great benefit for Linux as it would reduce the amount of code that has to be security reviewed and would open kernel development for new developers. But I get the criticism too. For one, the Linux kernel is constantly evolving. Asking kernel developers to add stable interfaces is going to be PITA for them, as soon as they start to tell you how it works they will want to change it. Also, and this is a criticism of rust itself, rust made a lot of decisions that are good on the desktop that are already problematic on the server but completely unworkable in the kernel (like assuming adding an element to a vector can never fail, operators being able to panic and so on) Also rust has some religious doctrine - like composition over inheritance - that makes sense in 99% of the time but it leads to poor separation of concerns and is not suitable for the big Linux kernel. I am thrilled about rust in the kernel, because it benefits rust more than the Linux kernel. And it opens the Linux kernel for a new generation of developers.

[@cyberpunkspike]

What company is that, so I can make sure never to invest in it.

[@Krmpfpks]

@@cyberpunkspike how nice of you to say that, I hope you have a beautiful day. I did make that decision many years ago when rust was still 0.9 and it surely was a gamble, but it did work out beautifully.

[@anonymousalexander6005]

Even on the kernel level, “running out of memory” is undefined behavior, the only ‘correct’ manner to deal with it is to PANIC. This is true even in firmware. The only way to truly control the behavior of “running out of memory” is to be able to run on the level of microcode. Ironically, it’s only when you get into controlled user space does “running out of memory” actually become reliably recoverable due to kernel/OS abstraction.

[@anonymousalexander6005]

@@cyberpunkspikewell you obviously would be a delightful investor to work with, so sad to see you go 😂

[@Krmpfpks]

@@anonymousalexander6005 i disagree. Many kernel functions have a return error code if there is not enough memory to complete the task. Even if an unrecoverable OOM arises the kernel needs to kill a single process (ideally the one causing the OOM) and not crash the entire machine. Look up „OOM killer“ in the search engine of your choice.

[@mskiptr]

appendix to my other comment: There are other ways to make that function total. Like you could have `first : NonEmpty -> T` where you use a separate data type of non-empty lists and so are guaranteed to always have at least one element.

[@mskiptr]

And that's still not the only way. But instead of explaining the even more advanced methods, let me instead show one cool thing from type theory. You know how with generics you can have a type variable that gets instantiated with some concrete type once use it and it just works with any type? You could also have a type-level integer somewhere there! You can have a function `getAtIndex : (Array, Fin) -> T`, where for example `Fin` is a type that contains only the values 0, 1 and 2. Then if the types all match (and your type system is sound), you can be sure that nobody is ever passing an out-of-bounds index to that function! Statically! And if that is indeed the case, you don't even need any runtime bounds checking!

[@isomeme]

If a C kernel change breaks compilation of Rust client code that explicitly encodes semantic assumptions, doesn't that mean that the kernel change could also be silently introducing runtime bugs into C client code that implicitly makes similar assumptions? It seems to me that a change to kernel semantics should require a careful review of all callers; Rust helps by making this mandatory. But I've never worked on the Linux kernel, so what am I missing?

[@mmstick]

Yes, that is exactly correct. If a change to a C interface breaks the Rust bindings, it is also breaking every C driver that uses those interfaces. What has been discovered is that many drivers are already silently broken, and this is why kernel driver developers want to use Rust to begin with.

[@isomeme]

@@mmstick, cool, thanks for the reality check. Objecting to Rust in Linux drivers because it exposes kernel problems at compile time is analogous to objecting to smoke detectors in homes because they make an annoying sound when they go off.

[@doublepinger]

The problem is Rust goes the full length and requires _possible_ bugs to be impossible. You want to extend hardware so a value can be volatile? Congrats that requires changing all of your Rust signatures, for everything that _could_ interact with it.

[@mmstick]

@@doublepinger I swear none of you have even looked at the Rust crates for Linux or embedded systems. Any changes you'd need to make for Rust code would be the same changes you'd need to make for C code. The ease of refactoring is one of Rust's greatest strengths over C.

[@isomeme]

@@doublepinger , to me that sounds like components should be more encapsulated, so you can change an implementation detail without changing API semantics.

[@swedishpsychopath8795]

At work, we have a similar problem: A few years ago it was allowed to use Kotlin on an equal footing with Java. Nice idea, but ended up being a nightmare to maintain code. When we hire developers, they now must master BOTH Kotlin and Java at expert level since you will encounter both syntaxes. For those who were already employed and did not know Kotlin, they were effectively downgraded to being "B programmers" and are not able to maintain large parts of the code base. We have super qualified Java developers that refuse to touch Kotlin code and we risk losing them and some has already left. You never know where Kotlin code has been mixed in and you constantly run the risk that a developer will come in who insists on using Kotlin and thus destroys the maintainability for the others. Allowing Kotlin is, in my view, the worst decision the company ever made.

[@peterfireflylund]

Kotlin is really not hard if you know Java. It is downright easy for a “super qualified” Java developer. You probably have a lot of not-so-qualified programmers at work.

[@swedishpsychopath8795]

@@peterfireflylund But it adds to the cognitive load and is TOTALLY UN-NECESSARY! Why stop at Kotlin? Why not allow ALL the Java JVM-dependent languages like Java, Kotlin, Scala, Groovy, Clojure, JRuby, Jython, Frege, Ceylon, Golo, Quercus, Fantom, Xtend, Mirah, TeaVM and others? Are you telling me this won't be a burden for everyone since you now risk to encounter all of these JVM-bytecode producing syntaxes everywhere and you'll either need to be an expert in all the mentioned languages yourself or you have to be dependent on somebody else? RUST should be STOPPED NOW! (and Kotlin too)

[@ShiroAisu10]

The difference is the gulf between what java offers and what kotlin offers is not every 1/100th of the gulf between rust and C. Also what "expert java devs" do you have that they can't pick up Kotlin in a week tops, lmao.

[@swedishpsychopath8795]

@@ShiroAisu10 Should they "pick up" the other Java JVM derivates too? Kotlin, Scala, Groovy, Clojure, JRuby, Jython, Frege, Ceylon, Golo, Quercus, Fantom, Xtend, Mirah, TeaVM? I'm sure they all are easy to learn? OR should we stick to ONE language to make life easier over all, even if Java isn't the slickest language (in some people minds)? To hell with it, let us include LISP too!!! I've heard it is the best language out there!

[@elaps]

@@swedishpsychopath8795 Java sucks compared to Kotlin and the concern you described was only about Kotlin, and not about every JVM language out there. Totally agree with @@ShiroAisu10 : "super qualified" devs couldn't spend few days learning Kotlin what the hell, they're either ossified or way overworked.

[@the-answer-is-42]

I don't think it's unreasonable to ask for better documentation, especially in a project as important as Linux. Even if we ignore Rust, better documentation can help C devs. It might even save a lot of peoples hairline if, say, s bunch of devs on a project dies in a buss crash and suddenly people have to maintain a new codebase.

[@supremesonicbrazil]

I don't hate Rust, honestly I'm pretty indifferent to it. But I do see one major flaw that could (and probably will) be the demise of it, and it is this: > "no one is trying to force anyone else to learn Rust" > proceeds to evangelize Rust like a vegan telling people that "meat is murder" and that "plants don't feel pain" (both are false statements btw) See, this is what I don't get. If "memory safety" is such a big deal that you have to create a whole new language to address it... why not just learn fucking Valgrind? Or better yet, work with the C/C++ committees so new revisions of the standard have those memory safety principles? That way we get the best of both worlds. Instead, all I see from the Rust crowd (based off of this video alone) is such an apocaliptic fear-mongering as if the world's gonna blow up if we don't care about the climate, or as if "we're special so cater to us else we're gonna cry on the internet". This along with the "official US govt. endorsement" they got a while ago makes it all sounds pretty sus to me. What exactly is the point here...? I surely hope it's not EEE, because right now it's exactly what it sounds like to me. When you get a bunch of evangelists like the GNOME and Wayland ones wanting to push this thing of theirs SO BAD, like "everything ever done has to be made the way we defined it because it's better and we know better, it's for the greater good". Yeah, no. I know how this shit plays out. You can keep on believing that inside your bubble, but if you want me to actually believe you, you have to get out of it someday and convince me with concrete and undisputable proof that your solution IS not only sufficiently better than what exists right now, but that it's actually ready for prime time, because that's how the world works. No amount of complaining on the internet is gonna change that. I've waited until Pipewire hit 1.0 so I could migrate to it, because no amount of hype-surfing justifies me migrating to a buggier, less mature solution that might not actually work for me. So why this incessant push for a less mature language? Can you, with a decent Rust code for , boost my CPU or GPU performance by at least 10%? Or give me an extra 10% of battery life on laptops? Can a Rust-equivalent of whatever program I happen to have here use at least 10% less RAM than if it were a C/C++ program? Where are the numbers? I just see general arrogance and ideological nonsense I and pretty much no one really cares about. The type of "victim mentality" that just makes me barf my lunch. They're never gonna be taken seriously if they keep acting like that.

[@gelbphoenix]

I think implementing Rust in the Kernel can lead to more people that contribute to the Kernel so it would mak the Kernel a bit future-proof. Also are there projects that wouldn't be in the state they are now if it wasn't for the Rust base (for example Asahi Linux for Macs based on the Apple M processors).

[@supremesonicbrazil]

@@gelbphoenix Still don't get why those people just don't learn Valgrind, it feels like taking extra steps to contour a path that'll end up in the same place. Or I dunno insisting in building a hovercraft to cross a river because it's more modern and whatever when they can just use a regular boat or even a kayak. Worse, insisting that "the hovercraft is de way" when the people they were evangelizing to have already crossed the damn river by themselves 5 minutes ago and instead of going after them they remain there complaining that they were left behind. The point is there's a lot of extra effort I'm seeing there that I don't see it being even necessary to begin with, if only people took the time to learn what they're dealing with. C/C++ was never "complicated" like most of those people like to whine about. If it was Assembly of all things then I might've given them a point, but C/C++ puts you in charge of yourself and that's a good thing long-term Same exact logic as the eternal discussion of "native Linux ports vs. using WINE/Proton". The answer is always "just fucking learn it". Also I really doubt the Asahi base couldn't be done in C if they really wanted to, the bigger problem there is Apple being fucking Apple and locking everything down so you would be forced by them to use Objective-C or Swift or whatever the fuck they force down people's throats nowadays. The point being there's the right tool for every occasion, and some tools like boasting themselves as "the swiss knives of computing" when they really aren't.

[@mmstick]

> Can you, with a decent Rust code for , boost my CPU or GPU performance by at least 10%? Or give me an extra 10% of battery life on laptops? Can a Rust-equivalent of whatever program I happen to have here use at least 10% less RAM than if it were a C/C++ program? Yes, the COSMIC Store uses a fraction of the memory that GNOME Software uses, and is 100x faster. COSMIC's already on path to be the fastest Wayland DE. Ripgrep is 10x faster than GNU Grep. etc., etc. That said, you are clearly not indifferent to Rust. You used a lot of very emotional language to discredit efforts by developers using Rust. The hatred you displayed is seething through your choice of language. > why not just learn fucking Valgrind It doesn't work. It just doesn't. Mozilla created Rust because Valgrind is not sufficient. Go read Google's security report, "Memory Safe Languages in Android 13". And come back to tell me that you seriously believe that runtime analysis is anywhere near as effective as Rust. Google determined that with even their best runtime analysis tools, these tools had no statistically significant impact on reducing vulnerabilities. Rust eliminated all of them. 1.4 million lines of Rust, written over a few years, and zero vulnerabilities to date.

[@username7763]

This too is my concern with Rust. Nothing wrong with new languages but if we are to fix memory safety in C, let's fix memory safety in C. Not re-write everything to a different language. Yes, there are already good tools that help with that, but they could still be improved.

[@supremesonicbrazil]

@@username7763 I'm pretty sure if saner standards were introduced in new C/C++ revisions (or new structs/functions/etc. that help with and/or abstract memory management a bit more akin to what Arch did with archinstall - it's there and you can use it if you want but you're not forced to), there wouldn't be such a resistance as there is now with Rust. As long as you don't take away the freedom of choosing (therefore not alienating people by forcing or removing things) people won't complain... much. Worst it could happen is no one uses the new thing and it gets deprecated later. The Rust people (and GNOME, and Wayland, etc.) seem to not understand that principle, pretty noticeable by how they don't seem to care about retrocompatibility because they think "it's all cruft that should be thrown away".

[@johnphamlore8073]

I'm surprised any language other than C finds it acceptable to basically regard pointers as unsigned longs, and to do tricks such as for red-black trees, where the color can be stored in the bits of a pointer that will never be used, because alignment requires such unused bits.

[@stanimir4197]

this is actually quite wrong, pointers being 64 bits are large enough to store info/metadata in them. Additionally CAS (compared and swap) on a 64bit is a lot cheaper than double-cas. Java for instance (can) use(s) compressed pointers on 64bit system and sub 32GB heap, where the pointers are 32bit shifted left 3 (so the lowest 3 bits are zero). Encoding class information in a 64bit pointer is another option... you just dont see it as it's "hidden". In C (or Asm) you can treat the reference/pointer any way you see fit, of course.

[@ToumalRakesh]

That bikeshedding session that was posted on youtube was a disgrace. The ignorance of C-only kernel devs was on full display. "I don't know anything about Rust, but ". "This looks like Java" "This looks like inheritance" "You'll never force me to learn Rust" My goodness. If you have a problem with something regarding Rust, like Linus did, that's fair and needs to be dealt with. And it's fine to have opinions. But plain old ignorance is not a substitute for an informed opinion, nor do I want that driving the development of my primary OS.

[@Zoverone]

It felt like someone was grasping the site of his discomfort.

[@LuluTheCorgi]

People's brain just kinda goes mush as they age and stuff like this is the result, it will happen to us too sadly

[@jonnyso1]

What I really appretiate about Linus is that when he gives his opinions about these kinds of things he's fundamentally technicall about it, even if he might show some emotion in the way he words it some times, the point is technical and objective. The feedback he gave to the rust project was straight to the point, "You wanna do this, it won't work because of that", the Rust guys got the feedback and addressed it. That's how things get done, the tech space is great because there is no need for zealots, you can be objective about things, but I guess human nature takes over more often then not sadly.

[@Nina-cd2eh]

It's crazy. 3 slides in and it was already derailed for nonsense. These people are allergic to even merely observing someone talk about Rust. It's pure ideology.

[@guguludugulu]

​@@Nina-cd2ehwhich is ironic from somebody screaming about religion of rust

[@janmkubalek]

There is a big misunderstanding - Rust programmers came to Linux, and added Rust even if everyone around was saying "But we will not help you. You have Rust there but do not expect us to support you, refactor C code because of Rust etc. "... And now - Rust developers complain that the C Devs do not want to help them, do not want to break existing code bases, etc. It is just LoL. Rust devs - you are on your own. Work hard, and prove that Rust is really good use case there. And maybe in 5, 10 years you convince stubborn users by hard work. Stop crying! Honestly, I have a feeling that the Rust devs do not know what it means to write a driver (for example PCIe). The C is just a tool. 90% of the work is to understand the HW, optimize it, and solve all bugs over the years.

[@Thyringer]

Rust is hype and propaganda. If you study the language intensively and approach it with a little more skepticism, you will see how poorly thought out everything is and how unnecessarily complicated the language itself. For hardware-related things like drivers and OS programming, Rust is simply unnecessarily abstract: You are more concerned with the language than with solving the problem. The only valid argument of the Rust disciples is the poor documentation of the C code of Linux.

[@ender5023]

Why not just make a Rust exclusive Linux-like kernal? It would give Rust devs so much freedom and would incentivise innovation. The unix-like micro kernal Redox is doing well (last I heard). Why argue with the C devs, especially when Rust and C are almost opposites in terms of the philosophy behind them as languages?

[@bountyjedi]

I've been studying a bit of Rust recently, and it feels more like an improved C++ to me than an improved C. It's definitely more on the "powerful & complex" end of the spectrum. Not sure if it's the best replacement for C, but it's a heck of a good replacement for C++. For simple userspace things I am rather fond of Golang, it's simplicity really is more like C, but it being reliant on a GC is not great for kernel and low-level development. Rust has the edge there. It's also not really quite as fast as Rust either (down to the language design and the compiler). I guess for the kernel some sort of Rust-- would make a lot of sense I guess, hah. Although it being no_std code, I guess in a sense it is? Something that is easier to learn for old C devs would be pretty nice too. Rust is quite a lot of effort to learn to be honest (and I still don't understand a lot of the finer nuances that you need to be on top of to write low-level code). I hear people talk about Zig a lot recently, but that does seem to not have quite the same amount of memory safety as Rust?. It does seem like it is more on the "simple and small" language scale like C though. And then of course there is Ada, which all the Rust evangelists conveniently forget when they proclaim Rust as the "first low-level memory-safe language suitable for systems programming". Honestly Ada would be pretty cool. It's even safer than Rust in some ways (In other ways Rust has it beat)

[@LuluTheCorgi]

The same thing we tell coal miners goes for C coders: further your education or fall behind and perish

[@rez188]

Rust's memory safety comes at the cost of a pretty massive increase in complexity. It's fine for single threaded apps, but once async or threading is added, suddenly everything needs a lifetime. It's an amazing language but the time investment required to get good at it is quite significant. That said, kernel development also takes a significant time investment so maybe it's worth it. Zig is much more like C, but vastly improved. There's namespaces, slices, booleans, methods, and comptime. Any C dev should feel right at home in zig, and once it reaches 1.0 I would be very suprised if Linus doesn't add it to the kernel as well. Right now it's just too unstable. Every update has massive breaking changes. The kernel doesn't need that

[@stefanalecu9532]

It's Ada, not ADA. Unless you really like the Americans with Disabilities Act. ;)

[@bountyjedi]

@@stefanalecu9532 Point taken, and post updated

[@bountyjedi]

@@LuluTheCorgi Eh, C isn't really going away any time soon. Heck, Fortran is still alive and kicking in this year of our lord 2024. Rust does do some things pretty well though, and I look forward to seeing more of it in the future. Although I feel it's far from a perfect design for various reasons. But perfect languages won't be ready in time to be adopted, just look at C. It's flawed as heck, but it gets the job done! (In fact that's an aspect of C I like. It's so simple you can often just focus on getting shit done, rather than focusing too much on the *how* and dribbling like 10 different ways of doing it in your mind)

[@brettfo]

Not just people who like rust. I hate rust and I think he makes a good point. Us old school devs need to get over it and start adopting tech to make our software safer.

[@electric26]

​@@sergioengineerWhy do you think compiling Rust is excruciating? Is it the waiting? Rust has been one of the most pleasant languages for me to ever use from a compiling standpoint, with an exception to the compile times (which have received significant improvements since I first started using it)

[@cyberpunkspike]

You hate rust, but you're fucking everyone because you're a weak bitch?

[@cyberpunkspike]

@@electric26 Rust sucks to program in, its community is degenerate, toxic sludge, You wanted this conflict, now it's time we give it to you.

[@brettfo]

@@sergioengineer If you have problems installing a compiler, maybe you should stick to stock kernels? I don't like writing rust code. The compiler and dev tooling are perfectly fine. Either way, this is not a good technical argument in support of not having rust in the kernel.

[@mmstick]

@@sergioengineer That's because Rust enables LTO by default, and GCC does not. Set it to off, install mold, and use sccache if you want super fast compile and link times. Regardless, static code analysis requires more CPU resources than a blind compiler that doesn't track or check anything but the most rudimentary patterns.

[@DanielDugovic]

Conclusion starts at 22:12 . Since we haven't seen a hostile fork yet (removing Rust), it's not a mistake.

[@RankAmatuer97]

Wait That's what their pissed about? Being asked to document their damn code?!

[@u9vata]

No, its thinking about lifetimes and ownership unnecessary much even when not in rust. The issue is that there are bunch of codes that the borrow checker would never accept - but vald and bug-free code. If you "accidentally" write such in C, now they have to think "okay how to say this to the rust people?" - and they just choose not to... let the rust furries figure it out and not take on extra work...

[@mkabilly]

@@u9vata And even if it is "just" about "documenting code" it is still an expectation that a completely unrelated dev working on something different than yourself that does not have the same motivations as you do some free labor that will benefit you.

[@ForeverZer0]

"We are just asking for a little documentation" is the salesman's pitch. I assume every person in that room is smart enough to read between the lines, especially after the first ~10 minutes that preceded it were a presentation on how Rust makes everything better is and is superior to C, in a room full of C devs who are likely sick of hearing the same pitch over and over.

[@u9vata]

@@ForeverZer0 Exactly. Also I looked up the guy in the presentation and Linus Torvalds continously have been complaining about this guy for him always pushing in huge (10k+ line) changes AFTER the merge window and expecting it still goes through - so basically not giving a shit about the common process that these should be between merge windows and not in untested ways in the end where you make a bunch of work... And here I talk about C code not Rust so it cannot be "because its rust" just not abiding rules. So I guess the other maintainers in the room also know this extra information and have worked with the guy...

[@jfbeam]

@@ForeverZer0 Rust works for userspace, not so much in the kernel. What appears to be "safe" in userspace, may not be in the kernel. There are a lot of protections that don't exist once you just to ring 0.

[@andythedishwasher1117]

Hey there's hardcore Linux folks here. Anybody got any takes on Odin and its chances at becoming a contender in the systems space? I'm absolutely loving it for game dev and the performance feels like it could serve a lot of purposes very well.

[@stefanalecu9532]

At this point, rewrite the kernel in Ada

[@kensmith5694]

I can remember when the future was all going to be ADA.

[@AleksyGrabovski]

+1 for Ada

[@cyberpunkspike]

@@kensmith5694 Anytime we got a train of zealots, declaring what the future will be, we must oppose, oppose, oppose.

[@pikaskew]

It’ll end up several gigs in size, but boy would it be easy to read

[@AleksyGrabovski]

@@pikaskew I don't think that Ada has a runtime that is much larger than Rust. But Ada has better types (new SPARK has also affine linear types for access types exactly as in Rust), it has contracts, invariants, very good memory layout adjustment (much needed in kernel), very good handling of interrupts and magic registers, etc, etc.

[@3Rton]

the comments section is stellar example why the project is probably doomed, doesn't inspire any hope with getting C and Rust people to talk lmao

[@cchutney348]

Judging by the comments, the culture war tards are the majority here. If only Linux was about free software and not owning the libs or bashing the fash. Even though the diet nazis are way overrepresented atm.

[@knm080xg12r6j991jhgt]

Hey, if it doesn't work out, they can put Rust in GNU Hurd 😜

[@ShiroAisu10]

C devs don't want to talk, they want to mald.

[@rusi6219]

​@@ShiroAisu10or maybe they actually want to do some programming as opposed to engaging with bad faith propaganda

[@commonsay4191]

@ShiroAisu10 You can say that when the keyboard army, fighting for an LLVM-based C++ clone, stops trying to justify shoehorning their language into an established codebase, instead of rewriting the project. If you want to change something so you can do your work *your way*, that's *your job*, and you can't force the last guys to do it for you. It doesn't matter if it's hard, or if you think it's bullshit.

[@DinoDiniProductions]

Yes, because it is never about software engineering principles, it's always about what club you are in.

[@ThePotatoChronicler]

8:09 The level of head-wall-collision I wanna perform from listening to him interrupt the speaker and ignore everything he is saying T_T

[@DarkerCry]

Eh, I can only see the Rust community trying to push on the C devs and continue losing. Rust might be a benefit but it isn't necessary at the end of the day. The community should just find people who are familiar with the C kernals as well as Rust and just entice them to work on documentation help. You can't expect a volunteer project to always do more when there is already a lot on their plate at the end of the day.

[@steeltormentors]

Zig would've been a better fit over Rust. One of Rust's main issues is it requires to be done in a specific "Rust way" of things which is too much hassle.

[@MortenBendiksen]

Most projects have people with preferences and their way probably need to be respected if changes are to occur over time, and the habits of those who drive the thing forward and stable and usable is part of the ecosystem.

[@totoroben]

See it's about branding. Rust decays a structure. They should have named the language stainless, or crabon fibre.

[@osakanone]

Crabs on fibre you say?

[@totoroben]

​@@osakanone heck yeh this one gets it

[@CptJistuce]

It really is a terrible name.

[@cyberpunkspike]

Rust is a completely honest name, now that you mention it. The fragility and brittleness imposed by its strangling type system decays all in to rust.

[@SuperSmashDolls]

@@cyberpunkspikeRust's type system is anything but brittle? Or at the very least, if you think it's brittle, you probably have shipped several high-severity CVEs in your lifetime. Otherwise, you're completely right about the name. In fact, the name was intentional: Mozilla's intent was a language that could seamlessly interop with and replace C code with itself.

[@meanmole3212]

Rust needs to get its 5hit together and prioritize getting the allocator API stabilized before it can start dreaming about entering the kernel space.

[@foobarf8766]

SIGILL bugs open over 1 year, it ain't ready and python just as fast for most things if you need memory safety

[@terryhayward7905]

I love the Iron Oxide on the whiteboard

[@FireStormOOO_]

This sure sounds like the Rust folks uncovering bugs and shaky assumptions left right and center in the existing C code and it bruising egos.

[@LabiaLicker]

>uses "folks" unironically opinion discarded

[@dmitripogosian5084]

The proof is in the pudding - whatever assumptions are shaky, it worked for 30 years in millions of deployments. Good enough. Kernel is to run hardware, not win a beauty pageant.

[@FireStormOOO_]

@@dmitripogosian5084 That works for stand alone code, it doesn't hold when you're providing an interface other developers are expected to use. An interface that only works correctly with the one implementation it's tightly coupled to is an abject failure as an interface.

[@dmitripogosian5084]

@@FireStormOOO_ But kernel as far as kernel space involved is , practically, a standalone project. It never aimed to provide stable API for in-kernel development. It does provide stable interface for user-space tools, but not for kernel parts.

[@dashcharger24]

Fork, and 10 years later, it will be merged back into one project. :) But seriously, I'm kinda with the Rust people, however it's really difficult if you aren't a kernel developer and don't know all the insights. Rust feels like Typescript for me. You cannot force people to use it, especially diehard plain JS developers. I suspect it's the same for C developers.

[@cchutney348]

Sure, but that comparison is hardly a good look for the C camp.

[@user-jm8fj7ez8s]

@@cchutney348It isn’t, but so is the nature of software… It’s very momentum based.

[@etherweb6796]

@@cchutney348 I mean TS doesn't make any runtime guarantees, and there's no well documented improvement in bugs when using TS over JS - but you do have to do a lot more typing if you use TS.

[@etherweb6796]

@@dashcharger24 Today I got an error from typescript saying "type string cannot be used in place of type string | object" - so we better hope Rust isn't like TS.

[@experimentalcyborg]

But nobody is forcing anyone to use Rust. It's like introducing Typescript to a vanilla JS project, and Typescript highlighting that a bunch of JS is not returning the same data type every time for the same function call. The JS implementation is just silently buggy and TS is making it visible for the first time. With the Linux kernel the problem is that the Rust compiler enforces that interfaces behave deterministically, and currently a lot of C kernel interfaces are an undocumented, nondeterministic mess. The usage of Rust isn't causing the problem, it's uncovering existing problems, just like the JS/TS example. A handful of maintainers of problematic bits of code are taking it personally and throwing tantrums instead of helping to make the Linux kernel more secure and reliable.

[@pioj]

Kernel mantainers seem worried about how optimistic Rust developers are plus they may be understimating future problems that Rust could bring along. But it's also visible how protective and skeptical mantainers are, like if they were about losing their homes...

[@wilfridtaylor]

I actually think writing a Linux compatible kernel in Rust could get DARPA funding and a lot of backing from the US government since they seem to be all in rewrite in rust at the moment.

[@makumbaDE]

Yup, the ADA initiative did that and has produced wonderful results.

[@horusfalcon]

@@makumbaDE Nice!