Also my experience, people are really bad about communicating what they are actually concerned about. Especially when it can perceived as an attack on another person. Saying "I am concerned about changing our bindings because I don't think a lot of these Rustacians won't be around in 5 years." is way harder to say than "This breaks my grep." Not a defense, but its a very human response.
A bigger amount of people suck ass at listening, plus the ADHD nature of most people nowadays would support the notion of his belief that they won't be there for support lmao.
I understand the perspective that they won't be there in 5 years. Every step rustacians take seems like a PR move to me. It's embedded in so many projects that they're a Rust project, as if that's a primary feature. Many blogs/videos with "rust software you should install on linux"-even if it's just a new version of ls or yet another package manager. I'm also concerned that many of those projects are just someone taking a very well known program and rewriting it in Rust simply to learn Rust better, which is fine. But it increases fragmentation, which is typical in new open source, but it does it in a way where it's most likely a dead-end. You can hack on a project in just about any language but Rust has a very significant barrier. And I'd argue that many code changes explode into massive PRs because of all the interdependancies Rust features introduce (lifetimes is what I think of mostly). They also shoehorn themselves into every discussion about bugs when most of what they argue is served just as well with managed languages. It's so slimy and so fake. You don't see that with most other languages. I haven't seen gophers doing any of this for example. And especially not by this point. Rust is so old. I can't tell if he's right about Rust going away, especially not that quickly, but I understand the perspective.
@@0xCAFEF00D That and the fact that it'll probably be abandoned or orphaned in a few years. I've experienced a core project being promoted as the next great thing, until it was shoved into production in hopes of fixing X thing. Then being abandoned in 1.5 years due to "it wasn't supposed to be used in production" and that "it had a few logical bugs" that was a byproduct of their inexperience.....that was cracked lmao
@@0xCAFEF00D It's how life goes, they start or advance in their careers and have less time for the fun stuff nothing wrong with that except when they leave a trail of abandoned projects, which in itself is alright but it's not alright when it has effect on something as important as Linux Kernel. Another thing that I couldn't help thinking is that for C developers any Rust code is a like a black hole.. when they break something in there they won't be bothered to learn a new programming language to go and fix it what is the ethos of Linux Kernel Development. The Rust guys saying "we'll take care of it", in best scenario the guy is sitting on his PR and waiting for some Rust guy to "handle it like he promised", seems that it's not worth the hassle.
Kernel maintainers use grep and text editors because for the longest time the kernel was far too large to load in an IDE. Most IDEs were designed to keep their code indexes in memory, but until fairly recently the kernel has been way too big for that.
I think it would be more accurate to say it was impossible to load the entire kernal at once. Most kernal devs still use neovim (which can be used as an IDE), since it allows reading one file at a time and moving between files VIA the shell. They would probably keep on working this way too, since kernal devs become VERY efficient with neovim
@@yalnisinfoI haven’t personally tried since around 2010. I expect on a beefy dev workstation it’s probably possible, especially in a lighter-weight IDE that pages code indexes. Also tools like treesitter and the like have made partial indexing a lot more useful. But really I doubt anyone who works on the kernel full time is bothering with that. Once people learn to use standard unix-style utilities as their IDE, they tend to stick with them as they’re super low latency, scale well, and let you do lots of things that are hard to do in typical IDEs anywhere near as quickly. It also tends to make you a lot faster at becoming productive in new code, as you learn to use free text search to very quickly jump to the areas of the code that are relevant to the changes you want to make.
@@monsterhunter445 No, it's not really just "closed source." There can be dictatorship in OSS as well. It's just there's one or a few people who dictate the direction to take the project in.
no, open source with a designated team to drive direction and goals. Meaning, features aren’t added or modified purely by public vote, but it’s a factor taken into account.
Not gonna lie, I use grep to navigate through my company's code base. Several years ago while I was removing code (code cleanup is a wonderful thing), I found references to the deprecated classes/methods that my IDE tools didn't discover. Ever since that point I've used grep and ripgrep to navigate my codebase
I remember writing some grep commands to filter through a 100GB log file into a second file then do a second pass filtering into a 3rd file. Because during night shifts and when nobody is looking I like to open VI and scroll with my mouse.
okay but no one has answered why rust code isn't greppable? it's all plain text?? the only difference is syntax but what are you grepping that isn't greppable in rust code?
@@CakeBossanno clue. I think the maintainer doesn't know much about rust, since the fn style function definitions are a lot more greppable than C code, where you have to adjust your coding style to make functions more greppable
John Carmack on Lex show "Almost every case i've seen when people mixed languages on a project that's a mistake. I would rather stay just in one language so that everybody can work across the entire thing."
Carmack wouldn't say that about a project where LoC is measured in multitudes of millions and developer base is thousands active contributors. He also would not say that about kernel, because assembly is a necessity for certain parts of the codebase.
You presume to know what Carmack would say? Carmack has worked on projects that are millions lines long with very large numbers of teams and yet said the above not long ago. I only quoted what he said about the subject.
@@gljames24 Furthermore, if circumstances play out the way some fear, C could go the way of COBOL: very few C devs who have to maintain a lot of legacy code across various fields, and then companies might actually have to force themselves to switch over to Rust because no new devs bothered with it.
@@gljames24 C is still everywhere. Starting with an arduino to learn the basics in some professions in trade school is something my stepson just did recently. Yeah I know, C in arduino isn't pure C but if you master that, you'll get there,
This made me chuckle, imagining any random tech drama happening and the one guy in charge of Rust code just throwing up his hands and saying "Fuck this shit, I'm out."
Mixing different languages, especially newer languages and especially completely different languages in a single monolithic project has always been problematic. Doing it in one the most critical infrastructure projects in the world is just stupid.
Is it though? They basically still write only in C, just want to experiment with the new language that has features that support the use case. They can completely disable rust with a flag anyway
Marcan (Hector Martin in this drama) might be right sometimes, wrong sometimes, knows his shit a lot, but he is truly insufferable in every sense of the word. I acknowledge his wisdom at the same time that I would never ever want to work with him in any project.
Yeah it sounds hellish. If you have to tip toe on eggshells around people it actively makes projects and the end product worse. It's a growing problem people like him are allowed to cause such toxicity under the assumption that they themself are the gold standard.
This isn’t the first project he’s crashing out of due to this shit, he keeps doing the same thing. He knows his technical stuff, but he can’t work with people.
@@ThePrimeTimeagenwhich means, what we might need is a good, well defined interface between 2 parts that comunicating, like http protocols, rest apis etc
No Linus Torvalds did not deal with the issue he blamed it on social media not the Linux maintainers who were actively sabotaging Rust. This issue will keep happening until Linus Torvalds starts banning Linux Maintainers who are sabotaging Rust due to their dislike of the programming language.
The rules are already in place. The kernel has flags to build without Rust, so the C developers and maintainers can ignore the Rust project entirely. The Rust for Linux project is to write nothing essential to the kernel. It's meant to start as drivers. The long wait has been because the RfL project is busy writing a ton of bindings to internal C apis that are needed before drivers can effectively be written. It just so happens that a lot of maintainers don't like the project for whatever reason, and keep blocking completely normal and innocuous patches, which leads to issues like this.
Software engineers are really excellent at creating problems where they don't exist. C is just fine for low-level development. Mixing everything up with bindings looks like a huge mess and a poop show about to happen in the future. What happens if Rust stops being a trendy shiny thing? What is the next shiny thing to put in it, then? ;)
Though I don't know rust yet, one thing I find concerning and haven't heard here yet, is that fact that you can't even develop for the kernel with a stable rust build. Only a nightly build with a truckload of patches that themselves will take years to make it into a stable rust distribution. Your a gift to the community. Thanks!
I think the fundamental problem is that no matter what, a single patch tends to have to be written by a single person. So, if you have one code-base with multiple languages, the single person writing a patch (PR) will have to make changes in whatever language the modules that are affected are written in. It's not realistic for Rust developers to claim they will take the responsibility to fix their own problems. That is just not how the real world works. They should accept that they are asking for C developers to maintain Rust code, and start from there. Otherwise, the arguments will never get anywhere.
That is why they want this driver added as a single layer they can work with, drivers downstream of it can just use it as a stable API then and if the C API changes they likely only need to change this one layer to continue to server the functions below. Else they have to implement it in every single downstream driver. They are offering to do the maintainence of this code, and if a single C maintainer doesn't want a mixed language codebase well, too bad, Linus has already made Linux a mixed language codebase.
@@EwanMarshall I don't understand why this interface can't be external to the DMA, a sort of Rust Driver Interface that does all the work the Rust devs have to do in their drivers right now, but doesn't touch the C code. Is this just bad practice or something? Are there major issues with this kind of interface? Why does it have to be in the DMA?
@ the patch didn't from the actual patch email it is acutally rust/kernel/dma: ``` rust/bindings/bindings_helper[.]h | 1 + rust/kernel/dma[.]rs | 271 ++++++++++++++++++++++++++++++++ rust/kernel/lib[.]rs | 1 + 3 files changed, 273 insertions(+) create mode 100644 rust/kernel/dma[.]rs ``` brackets added on the dots to stop youtube stupidely treating as links
What's the point of allowing Rust in the Kernel if you can't write upstream Rust bindings of the core APIs? Hector kind of destroyed the conversation but to me seems like Christoph was rage baiting. Linus allowing Rust made the Linux Project a C & Rust project, refusing to merge Rust because you have a vendetta against multi-language projects isn't fair when the project is publicly multi-language. I'd hazard what is worse than dealing with 2 languages is litigating whether or not having 2 languages is a good idea in every relevant patch set.
100% The time for all this frustration about multi-language projects to be aired was *before* Rust was explicitly permitted in the kernel. Linus already spoke, the kernel is now a multi-language project. If you don’t like it, tough titties, it’s the case now - your next steps are to work out how you’re going to work with it or leave
This is misleading, because most, if not all, of the Rust code in the kernel is support/infra/tooling stuff. The DMA api is core and moves quickly, so there is good reason to not want to clutter it with multi language support. It's not a vendetta, its fair criticism, and Rust support in Linux was greenlit under the command that it would be used in the right places, through process and consensus, where it's needed and appropriate. Not just a greenlight to start using Rust wherever.
@ to be clear the “process and consensus” part was blocked by Christoph who effectively said “pound sand”. I think everyone agrees some drivers written in Rust are a good idea. How many million lines of code is the Kernel now? 25? Lots of drivers need DMA. Generally, drivers need APIs. Otherwise, there is nothing to drive. A Rust driver that calls extern “C” functions every 4 lines is worthless. > most, if not all, of the Rust code… Doesn’t seem like a good point when the discussion is regarding about expanding the possibility for Rust drivers
From what I've seen, and this is admittedly limited, it seems a problem with framing. The prevailing opinion of the rust community appears to be that Rust is the future, and that everything else needs to make way for it. Unfortunately that's not how it works. Let's hypothetically say that this is in fact true that Rust is objectively superior in totality and not a matter of difference or tradeoffs. That's actually irrelevant, because in the end that's not THE factor that determines whether or not it is able to stay for the long run, it's more complex. You have the stability of the ecosystem, maintainability, the userbase, the dev base, just off the top of my head. In the context of, and in comparison to, the kernel, Rust is largely untested by time. Rust devs are the rookies, so to speak, and while a large amount of interest has put a spot light on them, no one knows how things are going to turn out, and even throwing out the people who just don't want rust to exist, that's going to make a lot of people nervous. At the end of the day, their excitement about Rust is not a good indicator of how well they'll be able to stick with the project, if anything, the drama is a bad sign, because at the end of the day, no matter how much you like your job, a lot of time it IS work. I disagree with Prime, at least on one option. Yes, one option is to just fork the kernel, which I don't believe is a good idea. In my limited understanding, I don't know that the Rust community, as it currently exists, is large, capable, and coherent enough all together to maintain it. If they could for a number of years though, that'd be pretty solid proof they can. The other option is not to just either let the project die, or wait for maintainers to phase out, it's to do the work. They are ultimately working on a project that's been in C for thirty years, they have to work around that, not the other way around. They have to build trust, a working methodology for interacting with both the C code and devs, and that realistically means they have to gut it out. For a time there are going to be growing pains, it's going to be a challenge figuring out how to work between the two languages, and that's not just on rust devs, whether the resistors like or or not, rust IS in the kernel and everyone's gotta work out what the best solution is, but rust devs are going to have to come to grips with the fact that they cannot dictate how things are going to work. They're going to have to understand just how much work is ahead of them, not just in code, but all the rest that comes with the job. Without that understanding and acceptance of the situation, they are going to be perpetually unhappy, because short of the equal uncertainty of forking, that is reality. Personally, I do feel like Zig may be the better fit, and with it's similarity to C, it does seem like a stronger contender for a future replacement of the majority of dev usage in the kernel, if not yet. However, while something about the rust language itself rubs me the wrong way, I would like it to succeed as a possibility for people to contribute in.
A lot of it comes down to the C maintainers. This particular patch, for instance, was a routine binding addition. Literally nothing special about it. It blew up only because the C maintainer said "over my dead body". Outside of the kernel I've barely seen any drama in years.
@14:05 I mean, it doesn't seem to be any worse a position than all C driver maintainers are in anyway? Like, if the API changes in a breaking way then every C driver is going to need to account for that too, it's not like the Rust people would be in a significantly worse boat.
I think the issue is a lack of trust in the statement that they will fully maintain it without blocking changes in C and without requiring features from the C side to enable the Rust side
Point is, there are quite likely a lot more C knowledgeable people in the kernel space than there are Rust knowledgeable people. You broke something that is in the C cbase and the person just kicked the bucket? 100 ready to step up to the plate. Same, but on the Rust cbase? "OK, anyone that can fill in on this and...". It's just a numbers thing. Echoes (to a point) a recent issue on a certain MS maintained nugget. Apple changed something that broke something and... there is only ONE (1!!!) expert on the subject working on that project and... he was on vacation. People couldn't build for close to a month, between him coming back and him fixing it.
Except almost every existing maintainer is highly experienced with C, so its not an issue - they can all work across the project. With this, you need a Rust guy to do it. They aren't guaranteed to be around.
@@AdrianVisan Linus has said that he's willing to ship a rust broken kernel. The only time that didn't happen, was because there was a failure of all side on the holidays and a patch had to be held back. That's it.
Zig is only an incremental improvement over C. It has some nice improvements, but not big enough of a difference where a lot of people who use C will switch to writing Zig. I can't imagine that, where it matters, Zig will overtake C in many environments. Rust, while much more complex, at least offers a different paradigm to C and can be just as performant.
@@kiramaticc Thats why rust wont replace C. The rust standard library cant even be used in the kernel because it crashes on out of memory. That applies to third party libraries too. Rust is too different from C. Zig removes all of the annoying parts of C. But the truth is that C is never going to get replaced. Neither by Zig nor Rust.
the sometimes wildly inconsistent response times of LSPs also just make certain features (most importantly autocomplete) very annoying to use even if everything works
As an embedded firmware engineer for a large company, I completely understand the hesitation to jump to something like Rust when everything is written in C/C++. The thought of doing re-writes and all the recursive testing to make sure it "works like it use too" while also developing for the currently working branches for mission critical FW, is a scary thing for old and new engineers.
It doesn't need to "work the way it used to," it needs to work the way it's supposed to. Break some eggs and make the omelette, the outcome is delicious even if the process is messy.
@@T1Oracle ehhhh honestly no i get where he's coming from. you don't realize the importance of "it works the way it used to" until some tool that takes advantage of some internal functionality Somewhere ends up breaking Mysteriously
5 years is not "experienced" when it comes to something like the Linux kernel. 5 years is like "ok, we'll start trusting you with something a little more challenging now". I don't mean 5 years programming Rust, I mean 5 years programming in the kernel. There are certainly plenty of experienced kernel devs who see the potential of Rust, but they are also the ones demanding integration is meticulous and robust. They are NOT rushing to convert the whole kernel to Rust.
So to be clear about this. There is a Rust for Linux project that is greenlit by Linus and is official. The features that it touches are experimental and do not block any kind of deployment - in fact by default the code is not even compiled. The C team does not need to do anything to welcome the Rust code - they only need to allow for the bindings to be committed. That puts the Rust team as the one that is receiving the API with no control over it (the worst position that one can be). The code does not touch anything inside the core functionalities - it is merely supposed to be a binding that is helpful to write the drivers in Rust - as to not write duplicated code Yet this maintainer still has a problem with it and is blocking it. Imo the pushback against the Rust in that kind of arrangement is kind of stupid
That discussion of semantic versioning, I'd have absolutely just said "Cool, have fun fixing this 'minor change' that broke everything", because that's ridiculously insane.
The problem with that is the person who is paying your salary has decided it's your job to fix it, not theirs. To me, it's a sign that I should start looking for a new job.
@jeffwells641 I figured the resignation was implied; would be pretty stupid to say that and not quit. I should have been more specific though. (Yes, I know it's not always practical to do it, but I'd do it as soon as it was)
1:55 I think the go to definition thing has been around for about 30 years, since the first W95 Borland IDEs. But Netbeans in 2004 definitely had that feature. They did it with custom parsers without LSPs, built their own ASTs and shit.
When I was trying to see when lsps were made google gave me this gem of an answer The concept of Language Service Providers (LSPs) has a long history, with the earliest forms of translation services dating back to 2500 BC when people used clay tablets to translate symbols.
The grep thing isn't only for "go-to definition", it's also for "where is this macro used in this category of drivers" from a perspective of configuring and understanding the Kernel, or where something is actually used. Also on some macros there's actually a complete different definition of what a function does, that hard for a LSP to handle.
The pumping lemma would disagree with you, but please tell me how a tool that can at best use regular expressions can somehow do things beyond what a tool that can parse context free grammars can. I'll be here waiting 'til eternity.
Nope. Because no other language has the amount of sycophants that rust does that feel the need to rewrite everything in their language. Even your average javascript dev realizes JS sucks and would rather write typescript. But even your typescript fanatic knows not to rewrite literally every project out there in typescript. Rust is the only programming language in which the sycophants demand that everything and anything be rewritten in it. These are the types of people that actually believe WebAssembly is going to somehow kill javascript. When in reality the complete opposite has happened. The web & javascript has killed normal app development.
Mostly it's the C diehards who are very dramatic. It often feels like those guys are the only ones who truly love their programming language. Most JS, Python and Java developers will tell you why they don't like their given language and typically they know a bunch of them. The language they happen to be using right now is simply because the previous codebase happened to be in it and they keep working with it. The C diehards are different. They love C with every fiber of their being. These guys even hate C++. To them, C is perfect and infallible and to even hint at replacing it is blasphemy that immediately gets some of them heated. Any problem anyone has with C is just a problem with the programmer. They are all-in on C for everything, not just for kernel design, but for everything. The idea of using any other language or god forbid, using OOP design principles, are anathema.
Every fanboy produces drama, the reason Rust gets so mentioned, in my opinion, is: more presence on social media, and the fact it's a possible mainstream alternative do C and C++, creating anxiety on c/c++ community I suppose. I do have a little experience about this in fact: sometime ago I asked on SDL reddit AMA about memory safety since langs like Rust was getting more traction due to it. I didn't said "hey rewrite in Rust!" or anything like that, it was just a question about how to ensure safety in C, but I got downvoted anyway 🤪
That was the objective take at the time. It still is. No mainstream OS written in Rust has shipped multiple successful and widely used versions. Until then, it's all subjective.
bro, we use delphi every day at work fuck embarcadero the deplhi 12 is a fuckin mess their IDE is more broken than ever and compiler constantly runs out of memory
The funniest thing is that the only ones who care about Linux being written in Rust are the Rust folks, who keep yelling at Linux. The kernel maintainers aren't interested, and the Linux Foundation also doesn't care about it since they keep reducing spending for Linux overall. Linus himself also seems to not care anymore.
I think their position is that they don’t specifically *want* rust in the kernel, they’re just willing to consider it if there’s a sufficiently compelling reason. I haven’t met many people who want rust in the kernel, but also haven’t met many who *don’t* want rust in the kernel
Rust folks are toxic, and Rust is probably the most overrated language ever. I am both Rust/C++ dev, and although I do enjoy Rust tools, I enjoy C++ way way more.
@@Zuftware if you claim there is something behind the scenes, why not share the clue? We don’t know what you’re talking about if you keep yelling about it like Rust folks
I don't know, all the dependents already break when a core API changes. Sometimes, the one making the change is also the one maintaining the dependency (driver, FS, whatever). In this case, Cristoph doesn't want to maintain the Rust depending on DMA. Well, just post your patches on DMA and cc the maintainers on the Rust consuming them???
I agree with Linus. This should be dry and technical to the point nobody would bother reading it on the socials media. Now the well is poisoned. I wouldn’t bring it up again for a year. I don’t know because I don’t put my time into it and probably should lol. No idea, no opinion. I can see potential issues both ways. My gut would say don’t add another language unless it is for a separate area ie backend frontend. 100% of maintainers can be used currently. Would this mean less?
He literally sabotaged himself. Christoph's stance was ostensibly dickish, but the damage Hector tried to inflict is the exact type of stuff to avoid....
@@DingleFlopHonestly, I don't even think the COC comment was the line Hector crossed. It was just Hector bashing on the Linux community and contribution process, which was unnecessary.
I wonder if Linus was dry and technical when he banned Russian developers from working on the Kernel just to comply with US regulations when the Linux kernel development should have nothing to do with geo-political issues.
The talk about shiny language of the day and the patch being a cancer that spreads over Linux was when tech talk ended. There would've been ways to make those points without belittling the work they were doing.
I don't know if it was editing or if you skipped it, but you missed another reply by Linus, a couple by Greg, and one from Ted. Ted basically said what you did about the maintainers not wanting to add things to the kernel unless they know people won't go away and that this has also happened with major C things like KVM support. He said that if people stick around and contribute more generally outside of their own directory and project they'll get further. Ted also specifically asked for upstream Rust to get to the point where the features needed to build Linux were in the main compiler and not considered "unstable" features, and to where there was a gcc frontend capable of building the kernel and not just the clang one. (Because the tooling to build with gcc and rustc is a point of friction.) Then one of the Rust guys popped in and said, I generally agree with this, but we have people who maintain multiple C drivers, have maintained them for 10+ years, and they want to use Rust for new driver code. So I don't see why *they* should be having their patches denied because otherwise we are just not going to have support for certain hardware and it will either be a major PITA for downstream having to apply their patches or a PITA for users because Linux distros don't like to offer configs with non-Linus repos. So as a practical matter things need to be in tree and hence go through the maintainers. There was also a discussion of why a fork isn't practical in general: the *relevant* people are maintaining other things in C code too. And the costs are too high. Even major feature initiatives fail when written in C because of current policies by some maintainers. That part of the discussion was more productive then some of the 'drama' / 'frustration' that made it into your final edited version form YT. Regardless, it's a hard problem. I don't know the solution. But, I generally agree with Ted's technical argument: Until the Rust tools needed to build the kernel are considered "stable" by the upstream compiler and the language as a whole is reliable enough to support multiple compiler backends (I.e. it at least has a gcc version as well as the clang one), then Rust code shouldn't be merging an official API into parts of the kernel where that upstream breakage can propagate. In the mean time, a bit of per driver duplication may be frustrating, but it isn't the end of the world. That said, I don't know enough about the build process to know if his argument is sound. Maybe the process is such that you can just turn the Rust stuff off if it breaks the ability to compile a build. Or perhaps the solution is to have a separate Rust driver interface maintainer who can be pulled from separately and who is responsible for maintaining that part of the code and making sure that Rust drivers work in general, that the build tools for Rust stay working, and so forth. Perhaps the wrong maintainers are being given the responsibility of handling it. Regardless, I'm very sympathetic to Ted's argument because similar considerations keep Rust from being used in a lot of projects (outside of big tech) where there just aren't the resources to deal with these kinds of shortcomings. And as much as I like the language, no matter where you are on the internet, you get backlash from Rust advocates who cannot accept that the language isn't "ready" for some use cases. Plenty of smart Rust people may be working on something, but if you point out that things still need work, Rust fans who don't even work in that field will get upset. RT_Preempt took almost a decade. So, this will probably be similarly slow. But it does seem like a lot of "the regulars" have a general sense of a long timeline that they want, and other long-time people feel like this is leading to bad technical decisions in the interim. And then there are a lot of other people who keep clogging up that conversation with the kinds of things that made up most of that thread even though they aren't the old hands who are familiar with the process and the people.
@@MaxHaydenChiz did they find a way to not duplicate the bindings in every driver without also cluttering the codebase in the way Christoph was concerned about?
@@falsemcnuggethope not as of the last time I read the thread. TBH, it's not clear to me how big of a problem this is. There's a big difference between 5 drivers and 50, especially if those handful of drivers are concentrated in a couple of manufacturer's hardware.
I love rust as a language and whenever i start a new project, I choose rust as my default. However, introducing it to an existing codebase like this seems like a massive pain and I definitely wouldn't want to be the one trying to fight to get it in, even though I for sure see the value in it
Never mix languages in a codebase. Don’t even mix related languages. Replace developers before replacing languages. If a developer wants a new language, cut of his write access. Mixed language codebases is a cancer. You want a new language, put it into a new project. That’s separate from the main project. And treat it as it’s separate project. With NO cross debugging between the two.
A separate project is worse. Now you have to re-invent everything between projects and cannot reuse. If you're going to use multiple languages ensure the bindings are seamless so you can still work effectively without duplicate effort.
But that's the problem: Linux needs the Rust devs. People like you and this maintainer forget why there's Rust in the Linux kernel to begin with. It's because big and very important driver maintainers will not write their extremely complex and critical drivers in C for no good reason. I mean, this is literally about whether the Linux kernel will get good support for nvidia graphics cards, or whether it will always be stuck as a toy. This is also a main question about "The linux desktop."
I would not agree on the related languages part. We moved a pure javascript project to typescript over time and we found countless bugs just by converting it. This added the complexity of strict types while removing the complexity of having to guess all the time what type something is and thus saved a lot of time and also helped us to find countless bugs. So on the front of "Dont mix related languages", i think it really depends on the languages itself.
15:25 this is why I assume that nobody knows how to properly use semvar and that every change is a breaking change. Because nobody knows how to properly use semvar and every change COULD be a breaking change.
Adding a second language to the kernel is the death of Linux mid-term. Terrible, terrible decision. Maintaining a project with two different languages is a massive PITA which will discourage any maintainer long-term. Not to forget that Rust is indeed the last shiny tool and might very well be replaced by something else a few years from now.
Not, adding a safe low level language is very good. It makes adding new complex features easier and safe. Google Funchia is an example of an OS where c and rust are being used, the old c code is left there, some of it is rewritten to rust, and the new code is created in rust
One thing to think about in the DMA aspect is if there is a ABI/interop issue between the Rust and C putting it in the kernel would crash the kernel vs in the driver it would only crash the driver. Theoretically no ABI/interop changes should get filtered before release but it is technically extra risk.
Tbh there's two mitigations A) the explicitly allowed rust code is mostly optional. It's all supposed to be in driver modules B) gcc is getting a rust frontend
It's possible to believe something needs to happen, but also recognize that it has negatives as well. Everything is a tradeoff. Corporate sponsorship, specifically.
Lsp is a specific protocol created by Microsoft in 2015. What you are thinking of is some kind of autocomplete. Implementations of that autocomplete varied from place to place. It used to be that only large IDEs targeted at specific languages could provide (smart) autocomplete.
Auto complete is not LSP. Before LSP every tool has to implement their own way of autocompletion. LSP is just a protocol that facilitates rhe decoupling of completion engine(language server) and completion interface(editor front end that shows and selects candidates). Which in turn enabling the widespread adoption of autocomplete functionality in editors.
21:56 if it's just a rust layer to abstract DMA (C code) for rust drivers, why is it even an issue? Hellwig won't have to fix nor interact with it. I don't get it
His issue is that the last time Rust broke the kernel the C devs had to hold off on patches until it was fixed. It’s a straightforward once burned twice shy situation where Hector/Asahi has burned his credibility.
They're just *saying *that Hellwig won't need to deal with it, but there's no reason for Hellwig to believe thats going to always be true. I can think of countless times where another team has told me: "We'll deal with it, it won't be your issue", and it indeed did become my issue. You can plausibly be afraid that it will become your issue in some way, and its happened before on the Linux project. They can say all they want: "It'll just be us maintaining it", but a very valid objection is: I don't want to rely on you to maintain it, I want everybody here to be able to maintain it.
This is a very good point which Prime skipped but it's there in LKML and make us understand why the pushback from C devs coz the point about them not having to deal anything with Rust is a lie. The C devs did receive a lot of pain. PRs got rejected because of failed Rust build in the kernel.
It sounds like if a C dev changes a C interface, that requires some changes in the Rust code to mirror the change as well or the rust will not compile. This breaks anything Rust related and possibly the whole Linux compilation as they are connected. This results in a situation that either the C devs have to also change the Rust code to mirror the API, or they merge broken code which is not ideal. I don't know really anything about the subject, just what I gathered from the vid.
@@pietraderdetective8953 > The C devs did receive a lot of pain. PRs got rejected because of failed Rust build in the kernel. Yea makes sense, but wouldn't that be the case for any C driver using core code ? When core code is updated, it's can break any upstream project no matter what language it's using. Am i missing something ?
About grep versus language servers. I use grep most of the time, because to put it simply, it works with any language in any environment. Setting up an LSP for a C++ project which is built to make setting up the LSP easy, thats fine, but if I get a random C or C++ codebase, I don't even try to use an LSP, because to set it up you first have to understand the full buildsystem. Even more so, a LSP that only works 90% of the time, can be worse than no LSP at all, because being bombarded with wrong errors, autocomplete screwing around and stuff like that is much worse than having just a dumb editor. Trying to be smart on limited information is worse than acknowledging you are dumb. That said, when I build my own project and choose my own tooling, I'm using an LSP.
Imagine some idiot who just started programming thinking Rust is better than C when they have barely written any significant amount of code of consequence! If Rust is sooooo good, why don't this Rust fanatics just write their own OS in Rust then instead of trying so hard to put Rust in C?
All the people calling it gatekeeping or "anti-rust" don't seem to understand that this would increasing the supported API footprint substantially, in a way that complicates back-compat concerns, etc. You don't really internalize that until you've had to deal with it.
breaking changes will have to be maintained in both cases whether there is duplicated code in each rust sub component or a top-level shared rust api. Given that rust _is_ accepted it should be done the best possible way (with no duplication). It seems to me there is one objectively better technical solution.
It is not true that responsibilities will land squarely on the Rust side if they maintain their code. You still end up with a less coherent system that breaks more easily as a product. Validation cycles will take longer to prevent this and it will take manpower, even from the C side!
I'm not familiar with these libraries, but every discussion about Rust in the kernel reads to me like someone trying to implement a strategy to replace an existing C component and take over that component, then getting angry when the person maintaining the existing code pushes back. Also "he used the word cancer *without repercussions*" is a giant red flag. As if everyone must be punished for using a word you don't like.
it's not about the word itself, it's the way a core maintainer chooses to talk about people trying to contribute to the kernel in a way he doesn't like.
To be fair, in this case the Rust wasn't trying to replace anything, and the consensus that has developed is that Rust is an addition, not a replacement. To be even more fair, the Rust code in this case was a middleware for the DMA api that many Rust drivers would need to use. If many Rust drivers end up writing their own code to consume the DMA api, then changes to the API would break all the drivers instead of the middleware. This change reduces the burden of maintaining Rust.
@@reybontje2375 But introduces Rust on a Core API that is used by everyone. Which I don't think is something reasonable when to compile the rust part you need a specific compiler/compiler configuration. You are forcing everyone to use a specific setup... (That was the "simple tooling" problem they talk about...)
@@framegrace1 That seems to be Linus's position. If you can't just grab gcc and compile the kernel, then Rust isn't ready to be in the Kernel. Someone in the thread was complaining that Linus used a combo of gcc and clang and that's why it didn't build. Well, that's the criteria. It needs to build in all the major tools they use, and that users are likely to use, and it needs to do so reliably. It sounds like Rust doesn't quite have that yet, so it's relegated to a side project and away from the core of the kernel.
Making a deal with a corpo is like a Faustian bargain, the senior devs who lived through Gates and others trying to fuck up Foss know this and are not naive enough to think Corporations do this bc of the goodness of their hearts. Thats just my humble opinion.
Neither do humans(guess what corproations are just bunch of humans witha commonish goal), my opinion is that moat people who work in oss dont do it because of goodness of their hearths but because they get something out of it even if its just fuzzy feelings
Hector sounds impossible to please, and when he isn't pleased, he wants go witch hunting and remove established people from the community who have opinions that oppose his. He acts entitled, literally grand standing and calling the maintainers entitled corporate shills, while literally doing this on donation money. He is paid by the community to deal with the community, it is his job!
It's definitely more of a late millennial, gen-z, gen-alpha tactic. Not that older devs wouldn't use it, it's just COC wasn't really a weapon that existed in early software, so older devs don't seem to reach for it as easily.
Imagine at work and 1 person in the team writes all their code in different language to the rest of the team who are working on an established product .. it would never fly.
@pluto8404 point of correction Go was created at Google, Dart was the official as they wanted to bring an alternative to JS and Java android development, Go had a whole another motive
@@bilbo_gamers6417 no it's not. It's far larger, complicated, and more important than that. And if it wouldn't be acceptable in a smaller less important code base, supported by a smaller team .. it follows that scaling any of those metrics just makes the proposal less desirable.
How do you navigate through code without ctags? Doesn't a compiler need to be involved in some way? The only LSPs I've used are hosted and use a database of CTAGS or similar files anyway that come out of a compiler.
correct. `ccls` (the main LSP for C/C++) needs a file which lists all the source files in the project and the compile commands. it then reads those to build its own index of your project (using llvm `libclang` under the hood)
10:40 Most communists think that all humans are like clones of one another, so all think and behave alike. The only reasons why there are unequal outcomes according to them is baseless bigotry of racism, sexism, etc.
The older I get, the more I find myself agreeing with the older generations that I used to hate. It feels like at least a portion of the Rust crew -- Hector, in this case -- are really just entitled children trying to use social media to force people to do what they think is best. Every time I see them talk, I lose respect for them more. And I hate that about myself. I miss the times when I could get excited about new technology instead of my first reaction being 'god now I'm going to have to deal with a bunch of zealots trying to force their new religion into everything'.
When you've had to deal with the fallback of overly enthousiast team members jumping on the latest craze (library/language/whatever) for a while, this is expected. Good tech HAS to prove its good, claims don't matter. It can't be rushed and it has to take time. There's nothing to hate about your perfectly sane first reaction. "Yeah, the demo looks cool. Let's see what the first waves of early devs will say about it twelve months from now..."
Using Rust in the kernel is like write a part of the constitution in another language. The readability an standardization in such big and complex projects are a valid technical point.
2:00 - I still use grep to search through a codebase. Not purely. But I often do. And the Linux kernel is too large and too complex for an IDE to handle.
rust in the kernel is the biggest mistake ever. it forces all kernel devs to master a language they never had the slightest interest in. and it attracts rustacians, meaning entitled brats who dislike thinking about memory management and believe the borrow checker lets them avoid that - news flash: it does not.
No actually it doesnt force older kernel devs to master new language and it brings in a whole new set of developers who would need to master a programming language just to try and join kernel development yes there will for lomg time be c devs but number will dvindle but kernel needs to keep going
@@bigpod old devs are better and they know codebase better. there is also no point of this overhyped shit language, because you still need to manage memory in drivers, so it defeats the whole point
@@Kerojey relying solely on old devs(old devs are devs who been developing certien codebase for some time) is not a good idea you should always have new devs come into the project, problem is barrier to entry into kernel development is overly high because you need to learn an old(age) language that honestly isnt the best at what it does. So allowing another language into the project isnt abad idea and any amount of technical protections regarding memory are better then no protections, wasnt in kernel around 1000 memory bugs(some security vulnerabilities) just in 2024 alone Do old devs bring tribal knowledge yes is that a justification to not allow newer ideas into the kernel no I think kernel has loads to improve its far from perfect in some ways worse then so hated windows kernel. Reality is kernel code should be written in whatever language you want not be gate kept to one archaic language reason for being chosen is because it existed at the time
Having to rely on tribal knowledge and old devs in an increasingly byzantine and endlessly changing kernel with internal apis changing massively between patches is a bad idea for continuing maintenance.
Calling Rust a cancer is pretty clever since the word cancer comes from the Greek word for crab. You could also call rust a blight since rust is named after a fungal plant disease.
linus is the root cause for all of this mess he is the one who decided to add rust to the linux kernel he dont mannage what boundries it will have or how to integrate it. even after multiple drama issues.
@gljames24 you think that someone like Linus and Linux doesn't find out about that sort of action far in advance? Linus agreed in Oct 2021, the nsa put out a report on the topic in jan 2022, So it was 3 months after not well after. Also i never said it was mandated. However is major goverment contractors who fund the Linux foundation start to put pressure fir what they know will be a long process. You saying it will have no effect?
23:39 He is right. It's that simple. This is a software engineering issue and that means it involves people. Cross project maintainability is project integrity is project success. Nothing wrong with multiple languages if you have factored it into resourcing -- but it inherently can't be in most open source projects. These must often mutuate past such problems by OS software evolution or rather natural selection - it's called forking.
If rust at the height of the hype is not able to endure at least 5 years of grinding fir a better position on a project that is 30yo, they dont have what it takes, and don't deserve said position. My hot take.
I don't think that's a hot take, I think that's reality. The kernel runs the world, everything in it's gotta be slow, or at least very deliberate. Jumping into that as a language whose whole thing is announcing that it's both better and drastically different and not expecting there to be years of growing pains seems incredibly unrealistic. Even it the only thing that was happening was migration, forget that there are still mostly C devs who are still very actively working on the kernel.
HOnestly Linux is on a death clock. Atleast this version of it is. Rust is fragile as hell, requiring extensive bindings and just some backwards ass thinking when paired with C languages directly. Honestly, It would also only take what.... one or two changes to the rust compilers to shatter the drivers as well?
Rust in the Linux Kernel is a classic example of Groupthink or "Going to Abilene". Prime lays out an ironclad case here for why this is just a bad idea - an outright stupid idea, even. It blows up the complexity of the project and blows up the accrual rate of technical debt, and subjects the whole thing to blow-ups in production. But a whole bunch of folks are chasing shiny objects without checking their baseline or seeing the bigger picture. Either they need to fork it completely or not at all. As a Linux user, this deeply troubles me because I am already dealing with the spectre of creeping enshittification in so many other areas of my life right now. I hope Linus weighs in heavily on this one and does the right thing, this project needs to last for decades to come.
They should rip Rust out sooner rather than later, before it becomes too entrenched in the kernel. Then make a separate fork that is maintained by Rust devs to port the kernel to Rust. That should make everyone happy, apart from the people who want to force their opinions on others.
Grep is the generic term for command line search tools. I dig the ability to tailor the search area and control the output. Don't knock it unless you try it!
So some people are coming into a project, that has had a strict standard for development for decades, and they want to insert their shiny new tools in there. The Linux kernel is not exactly the place to be testing your new language and having to split a project to multiple programming languages is very problematic.
I think forking linux for rust folks is the best course of action here. There's no point arguing with people who doesn't see the value of your work. Linux folks have their reasons, and it clearly isn't compatible with what the rust devs want.
Rust developers are big because it's easier to excel in rust than in safe c. How many bad drivers does linux have? It doesn't even have good nvidia drivers. Rust makes implementing complex features with safe very easy. So code low level complex multi core parallel programs to feel the experience
@@shining_cross From what I seen of rust, anything having to do outside the native language, and even some of that is extremely complicated. Just simple code where the developer has no full control of the memory layout has some benefits. To me that looks like an extremely poor fit for OS/driver development. Like, what can be possibly worse? Python maybe.
@@TheEVEInspiration Not, adding a safe low level language is very good. It makes adding new complex features easier and safer. Google Funchia is an example of an OS where c and rust are being used, the old c code is left there, some of it is rewritten to rust, and the new code is created in rust, there are more than 2 million of rust code there
24:21 Even John Carmack has mentioned the disadvantages of mixing two different languages in a single project, it increases complexity and adds friction to development.
@@nocodenoblunder6672 yes, it looks like it, and it's probably a good thing, in another comment I mentioned that it is a great opportunity for rust devs to be able to contribute, but it is going to be a big challenge for both parties to find a middle ground. A lot of patience will be required.
Linux needs hard boundaries. The idea that the entire kernel can be huge and monolithic and endlessly changing internally as one single unit is insane. The fact that api changes break rust is a sign that there are serious issues with kernel development. APIs should Not be constantly changing.
@bilbo_gamers6417 I agree with that, there must be a really good reason for changing an API, even if it's an internal one, and probably they should be a bit more considerate with all the people affected by that. To me, that feels like an intentional move to cause frustration to rust devs.
@@sarok21 Yes! I don't even care about Rust devs, honestly I think maybe having to include Rust can finally force the developers to put stable APIs into the kernel. if the Rust developers part ends up sucking super hard then you have your answer for if Rust should be in the kernel.
Great comment on “being nice even if the other side is not nice”. It can be incredibly frustrating, but being mean to everyone who isn’t nice to you sounds like a miserable life imo.
Unification is huge. We unified all to typescript. Now everybody is equally unhappy.
This i support
💀
so true I think about forking typescript on a regular basis
It's like having two children and giving them the same thing, even it's not the one any of them wanted the most.
@@ThePrimeTimeagenyou mean "TS I support"
Also my experience, people are really bad about communicating what they are actually concerned about. Especially when it can perceived as an attack on another person. Saying "I am concerned about changing our bindings because I don't think a lot of these Rustacians won't be around in 5 years." is way harder to say than "This breaks my grep." Not a defense, but its a very human response.
A bigger amount of people suck ass at listening, plus the ADHD nature of most people nowadays would support the notion of his belief that they won't be there for support lmao.
I understand the perspective that they won't be there in 5 years. Every step rustacians take seems like a PR move to me. It's embedded in so many projects that they're a Rust project, as if that's a primary feature. Many blogs/videos with "rust software you should install on linux"-even if it's just a new version of ls or yet another package manager. I'm also concerned that many of those projects are just someone taking a very well known program and rewriting it in Rust simply to learn Rust better, which is fine. But it increases fragmentation, which is typical in new open source, but it does it in a way where it's most likely a dead-end. You can hack on a project in just about any language but Rust has a very significant barrier. And I'd argue that many code changes explode into massive PRs because of all the interdependancies Rust features introduce (lifetimes is what I think of mostly). They also shoehorn themselves into every discussion about bugs when most of what they argue is served just as well with managed languages.
It's so slimy and so fake. You don't see that with most other languages. I haven't seen gophers doing any of this for example. And especially not by this point. Rust is so old. I can't tell if he's right about Rust going away, especially not that quickly, but I understand the perspective.
@@0xCAFEF00D That and the fact that it'll probably be abandoned or orphaned in a few years. I've experienced a core project being promoted as the next great thing, until it was shoved into production in hopes of fixing X thing. Then being abandoned in 1.5 years due to "it wasn't supposed to be used in production" and that "it had a few logical bugs" that was a byproduct of their inexperience.....that was cracked lmao
@@0xCAFEF00D It's how life goes, they start or advance in their careers and have less time for the fun stuff nothing wrong with that except when they leave a trail of abandoned projects, which in itself is alright but it's not alright when it has effect on something as important as Linux Kernel. Another thing that I couldn't help thinking is that for C developers any Rust code is a like a black hole.. when they break something in there they won't be bothered to learn a new programming language to go and fix it what is the ethos of Linux Kernel Development. The Rust guys saying "we'll take care of it", in best scenario the guy is sitting on his PR and waiting for some Rust guy to "handle it like he promised", seems that it's not worth the hassle.
Wait, you've really never used grep before?
Kernel maintainers use grep and text editors because for the longest time the kernel was far too large to load in an IDE. Most IDEs were designed to keep their code indexes in memory, but until fairly recently the kernel has been way too big for that.
does that mean it is possible to load it into an IDE now. Why?
@@yalnisinfo MacBook with M4 Max chip and 128Gb RAM makes a lot possible
I think it would be more accurate to say it was impossible to load the entire kernal at once. Most kernal devs still use neovim (which can be used as an IDE), since it allows reading one file at a time and moving between files VIA the shell. They would probably keep on working this way too, since kernal devs become VERY efficient with neovim
@@yalnisinfoI haven’t personally tried since around 2010. I expect on a beefy dev workstation it’s probably possible, especially in a lighter-weight IDE that pages code indexes. Also tools like treesitter and the like have made partial indexing a lot more useful. But really I doubt anyone who works on the kernel full time is bothering with that. Once people learn to use standard unix-style utilities as their IDE, they tend to stick with them as they’re super low latency, scale well, and let you do lots of things that are hard to do in typical IDEs anywhere near as quickly. It also tends to make you a lot faster at becoming productive in new code, as you learn to use free text search to very quickly jump to the areas of the code that are relevant to the changes you want to make.
@@voidwalker7774 Imagine programming Linux Kernel on freakin macbook (and start writing GigaBytes with GB).
Rust in the linux kernel is a project so long, that its duration is only matched by the time primagen will need to migrate to wayland
It's very new by Linux kernel standards. Have to keep that in mind.
I think the only way it will be done efficiently is AI. Test Code Repeat. The Ship of Theseus
I really hate democracy in software development. Benevolent dictatorship is so much better.
So closed software then ok lol
@@monsterhunter445 No, it's not really just "closed source." There can be dictatorship in OSS as well. It's just there's one or a few people who dictate the direction to take the project in.
no, open source with a designated team to drive direction and goals. Meaning, features aren’t added or modified purely by public vote, but it’s a factor taken into account.
@@monsterhunter445 You don't know what closed source mean.
Informed captain and dictator
Not gonna lie, I use grep to navigate through my company's code base. Several years ago while I was removing code (code cleanup is a wonderful thing), I found references to the deprecated classes/methods that my IDE tools didn't discover. Ever since that point I've used grep and ripgrep to navigate my codebase
Just curious, what IDE?
I remember writing some grep commands to filter through a 100GB log file into a second file then do a second pass filtering into a 3rd file. Because during night shifts and when nobody is looking I like to open VI and scroll with my mouse.
Greppable is a signal for consistency. If it's greppable, it probably also takes less attention for humans to grep it.
this.
how do i know without LSP that this code is run with the bazillion #ifdefs before it
okay but no one has answered why rust code isn't greppable? it's all plain text?? the only difference is syntax but what are you grepping that isn't greppable in rust code?
@@CakeBossanno clue. I think the maintainer doesn't know much about rust, since the fn style function definitions are a lot more greppable than C code, where you have to adjust your coding style to make functions more greppable
You grepped by attention
John Carmack on Lex show
"Almost every case i've seen when people mixed languages on a project that's a mistake. I would rather stay just in one language so that everybody can work across the entire thing."
Front end dev :D
At this stage they'd be better off rewriting the whole thing in rust
Carmack wouldn't say that about a project where LoC is measured in multitudes of millions and developer base is thousands active contributors. He also would not say that about kernel, because assembly is a necessity for certain parts of the codebase.
You presume to know what Carmack would say? Carmack has worked on projects that are millions lines long with very large numbers of teams and yet said the above not long ago. I only quoted what he said about the subject.
@@doresearchstopwhining good, i would like to see you start today
New C devs are being born everyday. Anyone who thinks that new programmers are only using new languages is living in a bubble.
Not as much as before. Rust is the new hotness with teen prodigy types. I seen it
The problem isn't that people aren't learning C, it's the time to become competent in safe C is higher than writing safe Rust.
@@gljames24 Furthermore, if circumstances play out the way some fear, C could go the way of COBOL: very few C devs who have to maintain a lot of legacy code across various fields, and then companies might actually have to force themselves to switch over to Rust because no new devs bothered with it.
@@mattmmilli8287New hotness, like python and C++ were?
@@gljames24 C is still everywhere. Starting with an arduino to learn the basics in some professions in trade school is something my stepson just did recently. Yeah I know, C in arduino isn't pure C but if you master that, you'll get there,
I have to conclude that Rust is so mentally taxing which is why every Rust guy keeps resigning in every drama
This made me chuckle, imagining any random tech drama happening and the one guy in charge of Rust code just throwing up his hands and saying "Fuck this shit, I'm out."
They're joining the 41%
@@isodoublet I need som explanation on this one.
@@saybrowt if you don't know, you're better off finding out in a different forum than UA-cam comments
@@saybrowtIf I remember correctly, the joke is trans suicide. (And also of course very inaccurate) Also implying that all rust devs are trans/queer.
59:05 you mean to say, we should be willing to be introspective and forgiving sometimes?? Anathema! /s
hey it's you!!!
@@tcc1234 You too!
Mixing different languages, especially newer languages and especially completely different languages in a single monolithic project has always been problematic. Doing it in one the most critical infrastructure projects in the world is just stupid.
Why switch to cars when we already have horses!
👴📣☁️
Is it though? They basically still write only in C, just want to experiment with the new language that has features that support the use case. They can completely disable rust with a flag anyway
@@T1Oracle it’s more like: I have a horse and replace one hoof with a wheel
Marcan (Hector Martin in this drama) might be right sometimes, wrong sometimes, knows his shit a lot, but he is truly insufferable in every sense of the word. I acknowledge his wisdom at the same time that I would never ever want to work with him in any project.
he is same type of person like drew devault lol
Didn't he brag about booting some 19 year old from freedesktop for having the wrong opinions?
Yeah it sounds hellish. If you have to tip toe on eggshells around people it actively makes projects and the end product worse. It's a growing problem people like him are allowed to cause such toxicity under the assumption that they themself are the gold standard.
@@kexec.can you elaborate?
This isn’t the first project he’s crashing out of due to this shit, he keeps doing the same thing.
He knows his technical stuff, but he can’t work with people.
As someone working in a multi language project, I’m going to side strongly with “team C only”😅. Making Multi language PRs go green is the sux0rz
All my experiences when it comes to that have been bad unless it's front end / back end, then it seems fine
@@ThePrimeTimeagenwhich means, what we might need is a good, well defined interface between 2 parts that comunicating, like http protocols, rest apis etc
@@ThePrimeTimeagen so what you are saying is... bundle react with linux?
agreed, rust is cool but if you want to do rust as well there needs to be a VERY clear separation between the c and the rust parts.
@@ThePrimeTimeagenarguably that's 2 code bases, one product, and not a single codebase
I really think that if Linus is trying to add rust to the kernel it should define more clear rules on how it should work to avoid this kind of drama.
He did. He said he will deal with it. The problem was that someone in the rust side jumped the gun, obviously frustrated and called for a mob.
No Linus Torvalds did not deal with the issue he blamed it on social media not the Linux maintainers who were actively sabotaging Rust. This issue will keep happening until Linus Torvalds starts banning Linux Maintainers who are sabotaging Rust due to their dislike of the programming language.
@ I won't go so far as to ban them, but there needs to be a "tiebreaker" policy by him, so that this bikeshedding doesn't go on long.
Drama is the lifeblood of humanity.
The rules are already in place. The kernel has flags to build without Rust, so the C developers and maintainers can ignore the Rust project entirely. The Rust for Linux project is to write nothing essential to the kernel. It's meant to start as drivers. The long wait has been because the RfL project is busy writing a ton of bindings to internal C apis that are needed before drivers can effectively be written. It just so happens that a lot of maintainers don't like the project for whatever reason, and keep blocking completely normal and innocuous patches, which leads to issues like this.
There is a reason C has existed for 50 years without a CoC, a community or even a mascot. It will be around for another 50 and beyond.
Software engineers are really excellent at creating problems where they don't exist.
C is just fine for low-level development. Mixing everything up with bindings looks like a huge mess and a poop show about to happen in the future.
What happens if Rust stops being a trendy shiny thing? What is the next shiny thing to put in it, then? ;)
Though I don't know rust yet, one thing I find concerning and haven't heard here yet, is that fact that you can't even develop for the kernel with a stable rust build. Only a nightly build with a truckload of patches that themselves will take years to make it into a stable rust distribution.
Your a gift to the community.
Thanks!
I think the fundamental problem is that no matter what, a single patch tends to have to be written by a single person. So, if you have one code-base with multiple languages, the single person writing a patch (PR) will have to make changes in whatever language the modules that are affected are written in. It's not realistic for Rust developers to claim they will take the responsibility to fix their own problems. That is just not how the real world works. They should accept that they are asking for C developers to maintain Rust code, and start from there. Otherwise, the arguments will never get anywhere.
That is why they want this driver added as a single layer they can work with, drivers downstream of it can just use it as a stable API then and if the C API changes they likely only need to change this one layer to continue to server the functions below. Else they have to implement it in every single downstream driver. They are offering to do the maintainence of this code, and if a single C maintainer doesn't want a mixed language codebase well, too bad, Linus has already made Linux a mixed language codebase.
@@EwanMarshall I don't understand why this interface can't be external to the DMA, a sort of Rust Driver Interface that does all the work the Rust devs have to do in their drivers right now, but doesn't touch the C code. Is this just bad practice or something? Are there major issues with this kind of interface? Why does it have to be in the DMA?
@ the patch didn't from the actual patch email it is acutally rust/kernel/dma:
```
rust/bindings/bindings_helper[.]h | 1 +
rust/kernel/dma[.]rs | 271 ++++++++++++++++++++++++++++++++
rust/kernel/lib[.]rs | 1 +
3 files changed, 273 insertions(+)
create mode 100644 rust/kernel/dma[.]rs
```
brackets added on the dots to stop youtube stupidely treating as links
What's the point of allowing Rust in the Kernel if you can't write upstream Rust bindings of the core APIs? Hector kind of destroyed the conversation but to me seems like Christoph was rage baiting. Linus allowing Rust made the Linux Project a C & Rust project, refusing to merge Rust because you have a vendetta against multi-language projects isn't fair when the project is publicly multi-language.
I'd hazard what is worse than dealing with 2 languages is litigating whether or not having 2 languages is a good idea in every relevant patch set.
100%
The time for all this frustration about multi-language projects to be aired was *before* Rust was explicitly permitted in the kernel. Linus already spoke, the kernel is now a multi-language project. If you don’t like it, tough titties, it’s the case now - your next steps are to work out how you’re going to work with it or leave
It will no longer be GNU/Linux. Since GNU has official recommendations of C or Lisp. No Rust. Lisp took a very long time to make it on the list.
This is misleading, because most, if not all, of the Rust code in the kernel is support/infra/tooling stuff. The DMA api is core and moves quickly, so there is good reason to not want to clutter it with multi language support. It's not a vendetta, its fair criticism, and Rust support in Linux was greenlit under the command that it would be used in the right places, through process and consensus, where it's needed and appropriate. Not just a greenlight to start using Rust wherever.
@@mrquicky GNU is seperate to the Linux kernel, that is the whole point of the phrase "GNU/Linux" .they are different projects.
@ to be clear the “process and consensus” part was blocked by Christoph who effectively said “pound sand”.
I think everyone agrees some drivers written in Rust are a good idea. How many million lines of code is the Kernel now? 25? Lots of drivers need DMA. Generally, drivers need APIs. Otherwise, there is nothing to drive. A Rust driver that calls extern “C” functions every 4 lines is worthless.
> most, if not all, of the Rust code…
Doesn’t seem like a good point when the discussion is regarding about expanding the possibility for Rust drivers
Why is Rust always surrounded by so much drama ? It seems like every week there is some new drama related to rust.
From what I've seen, and this is admittedly limited, it seems a problem with framing. The prevailing opinion of the rust community appears to be that Rust is the future, and that everything else needs to make way for it. Unfortunately that's not how it works. Let's hypothetically say that this is in fact true that Rust is objectively superior in totality and not a matter of difference or tradeoffs. That's actually irrelevant, because in the end that's not THE factor that determines whether or not it is able to stay for the long run, it's more complex. You have the stability of the ecosystem, maintainability, the userbase, the dev base, just off the top of my head. In the context of, and in comparison to, the kernel, Rust is largely untested by time. Rust devs are the rookies, so to speak, and while a large amount of interest has put a spot light on them, no one knows how things are going to turn out, and even throwing out the people who just don't want rust to exist, that's going to make a lot of people nervous. At the end of the day, their excitement about Rust is not a good indicator of how well they'll be able to stick with the project, if anything, the drama is a bad sign, because at the end of the day, no matter how much you like your job, a lot of time it IS work. I disagree with Prime, at least on one option. Yes, one option is to just fork the kernel, which I don't believe is a good idea. In my limited understanding, I don't know that the Rust community, as it currently exists, is large, capable, and coherent enough all together to maintain it. If they could for a number of years though, that'd be pretty solid proof they can. The other option is not to just either let the project die, or wait for maintainers to phase out, it's to do the work. They are ultimately working on a project that's been in C for thirty years, they have to work around that, not the other way around. They have to build trust, a working methodology for interacting with both the C code and devs, and that realistically means they have to gut it out. For a time there are going to be growing pains, it's going to be a challenge figuring out how to work between the two languages, and that's not just on rust devs, whether the resistors like or or not, rust IS in the kernel and everyone's gotta work out what the best solution is, but rust devs are going to have to come to grips with the fact that they cannot dictate how things are going to work. They're going to have to understand just how much work is ahead of them, not just in code, but all the rest that comes with the job. Without that understanding and acceptance of the situation, they are going to be perpetually unhappy, because short of the equal uncertainty of forking, that is reality. Personally, I do feel like Zig may be the better fit, and with it's similarity to C, it does seem like a stronger contender for a future replacement of the majority of dev usage in the kernel, if not yet. However, while something about the rust language itself rubs me the wrong way, I would like it to succeed as a possibility for people to contribute in.
A lot of it comes down to the C maintainers. This particular patch, for instance, was a routine binding addition. Literally nothing special about it. It blew up only because the C maintainer said "over my dead body". Outside of the kernel I've barely seen any drama in years.
Research the particular people involved. There are repeat offenders
because rust is shit build around borrow checker which is cool idea but shit too
because it's not a language it's a political movement and people don't want it around.
Hector was tired - that's a fact. Imagine typing all that huge text using only service desk bell
Oh honey, “dea” isn’t a word…
@14:05 I mean, it doesn't seem to be any worse a position than all C driver maintainers are in anyway? Like, if the API changes in a breaking way then every C driver is going to need to account for that too, it's not like the Rust people would be in a significantly worse boat.
Things were working
I think the issue is a lack of trust in the statement that they will fully maintain it without blocking changes in C and without requiring features from the C side to enable the Rust side
Point is, there are quite likely a lot more C knowledgeable people in the kernel space than there are Rust knowledgeable people. You broke something that is in the C cbase and the person just kicked the bucket? 100 ready to step up to the plate. Same, but on the Rust cbase? "OK, anyone that can fill in on this and...". It's just a numbers thing.
Echoes (to a point) a recent issue on a certain MS maintained nugget. Apple changed something that broke something and... there is only ONE (1!!!) expert on the subject working on that project and... he was on vacation. People couldn't build for close to a month, between him coming back and him fixing it.
Except almost every existing maintainer is highly experienced with C, so its not an issue - they can all work across the project. With this, you need a Rust guy to do it. They aren't guaranteed to be around.
@@AdrianVisan Linus has said that he's willing to ship a rust broken kernel. The only time that didn't happen, was because there was a failure of all side on the holidays and a patch had to be held back. That's it.
I can see Zig replacing C in 20 years rather than Rust.
rust is my favourite lang and I still agree with you
Zig is only an incremental improvement over C. It has some nice improvements, but not big enough of a difference where a lot of people who use C will switch to writing Zig. I can't imagine that, where it matters, Zig will overtake C in many environments. Rust, while much more complex, at least offers a different paradigm to C and can be just as performant.
@@kiramaticc Thats why rust wont replace C. The rust standard library cant even be used in the kernel because it crashes on out of memory. That applies to third party libraries too. Rust is too different from C. Zig removes all of the annoying parts of C. But the truth is that C is never going to get replaced. Neither by Zig nor Rust.
I have been thinking of rewriting parts of the linux kernel in Zig or Rust, or both but I lean towards Zig.
Rust is, at most, a replacement of C++, but tbh since 2011 and C++ incrementally improving on C++ it has rapidly caught up
I've had LSPs crash in 20k LOC projects, turning that on in the Linux kernel you might as well power off your computer.
Shitty LSP then
😅😅
I use it just fine for the kernel
the sometimes wildly inconsistent response times of LSPs also just make certain features (most importantly autocomplete) very annoying to use even if everything works
clangd+neovim works fine for me, no issues loading the entire kernel
As an embedded firmware engineer for a large company, I completely understand the hesitation to jump to something like Rust when everything is written in C/C++. The thought of doing re-writes and all the recursive testing to make sure it "works like it use too" while also developing for the currently working branches for mission critical FW, is a scary thing for old and new engineers.
skill issue
It doesn't need to "work the way it used to," it needs to work the way it's supposed to. Break some eggs and make the omelette, the outcome is delicious even if the process is messy.
@@T1Oracle ehhhh honestly no i get where he's coming from. you don't realize the importance of "it works the way it used to" until some tool that takes advantage of some internal functionality Somewhere ends up breaking Mysteriously
You misrepresented the whole "it's newcomers wanting to use rust", it's not. R4L has been championed by very experienced and active contributors.
how experienced can they really be if they think multi-language projects are a good idea, for a kernel no less.
5 years is not "experienced" when it comes to something like the Linux kernel. 5 years is like "ok, we'll start trusting you with something a little more challenging now". I don't mean 5 years programming Rust, I mean 5 years programming in the kernel. There are certainly plenty of experienced kernel devs who see the potential of Rust, but they are also the ones demanding integration is meticulous and robust. They are NOT rushing to convert the whole kernel to Rust.
So to be clear about this.
There is a Rust for Linux project that is greenlit by Linus and is official. The features that it touches are experimental and do not block any kind of deployment - in fact by default the code is not even compiled. The C team does not need to do anything to welcome the Rust code - they only need to allow for the bindings to be committed. That puts the Rust team as the one that is receiving the API with no control over it (the worst position that one can be). The code does not touch anything inside the core functionalities - it is merely supposed to be a binding that is helpful to write the drivers in Rust - as to not write duplicated code
Yet this maintainer still has a problem with it and is blocking it.
Imo the pushback against the Rust in that kind of arrangement is kind of stupid
That discussion of semantic versioning, I'd have absolutely just said "Cool, have fun fixing this 'minor change' that broke everything", because that's ridiculously insane.
The problem with that is the person who is paying your salary has decided it's your job to fix it, not theirs. To me, it's a sign that I should start looking for a new job.
@jeffwells641 I figured the resignation was implied; would be pretty stupid to say that and not quit. I should have been more specific though. (Yes, I know it's not always practical to do it, but I'd do it as soon as it was)
1:55 I think the go to definition thing has been around for about 30 years, since the first W95 Borland IDEs. But Netbeans in 2004 definitely had that feature. They did it with custom parsers without LSPs, built their own ASTs and shit.
When I was trying to see when lsps were made google gave me this gem of an answer
The concept of Language Service Providers (LSPs) has a long history, with the earliest forms of translation services dating back to 2500 BC when people used clay tablets to translate symbols.
I legit laughed that was good.
I got “An AI Overview is not available for this search”, brilliant.
BC2500 kids complaining how their moms bought them Clay Tab S9 instead of iClay 16
I'm surprised it took them this long to the Rust folks to invoke the code of conduct , but still, it was all well predicted.
Code of Conduct is another money scheme and filter to remove good workers.
The grep thing isn't only for "go-to definition", it's also for "where is this macro used in this category of drivers" from a perspective of configuring and understanding the Kernel, or where something is actually used. Also on some macros there's actually a complete different definition of what a function does, that hard for a LSP to handle.
The pumping lemma would disagree with you, but please tell me how a tool that can at best use regular expressions can somehow do things beyond what a tool that can parse context free grammars can.
I'll be here waiting 'til eternity.
@@zakhoskins6404 You've done this in a single project with 40 million lines of code? And found every instance? And didn't crash?
Is there any other language that produces so much drama as Rust?
Node does not even come close!!!! LOL
Nope. Because no other language has the amount of sycophants that rust does that feel the need to rewrite everything in their language.
Even your average javascript dev realizes JS sucks and would rather write typescript. But even your typescript fanatic knows not to rewrite literally every project out there in typescript.
Rust is the only programming language in which the sycophants demand that everything and anything be rewritten in it.
These are the types of people that actually believe WebAssembly is going to somehow kill javascript. When in reality the complete opposite has happened. The web & javascript has killed normal app development.
Nothing beats c. Crowdstrike incident alone more drama than all rust combined
Mostly it's the C diehards who are very dramatic. It often feels like those guys are the only ones who truly love their programming language. Most JS, Python and Java developers will tell you why they don't like their given language and typically they know a bunch of them. The language they happen to be using right now is simply because the previous codebase happened to be in it and they keep working with it.
The C diehards are different. They love C with every fiber of their being. These guys even hate C++. To them, C is perfect and infallible and to even hint at replacing it is blasphemy that immediately gets some of them heated. Any problem anyone has with C is just a problem with the programmer. They are all-in on C for everything, not just for kernel design, but for everything. The idea of using any other language or god forbid, using OOP design principles, are anathema.
Every fanboy produces drama, the reason Rust gets so mentioned, in my opinion, is: more presence on social media, and the fact it's a possible mainstream alternative do C and C++, creating anxiety on c/c++ community I suppose.
I do have a little experience about this in fact: sometime ago I asked on SDL reddit AMA about memory safety since langs like Rust was getting more traction due to it.
I didn't said "hey rewrite in Rust!" or anything like that, it was just a question about how to ensure safety in C, but I got downvoted anyway 🤪
I think Hellwig's self-professed objectivity toward Rust was backpedaling. Prior to that, he referred to it as "your shiny language of the day."
That was the objective take at the time. It still is. No mainstream OS written in Rust has shipped multiple successful and widely used versions. Until then, it's all subjective.
@@blarghblargh "erm um nobody has made an OS kernel entirely in rust that has more than a million users so it's a gimmick"
Delphi is very greppable and memory safe, we should put it in the linux kernel :P
I wanna use Basic
bro, we use delphi every day at work
fuck embarcadero
the deplhi 12 is a fuckin mess
their IDE is more broken than ever
and compiler constantly runs out of memory
The funniest thing is that the only ones who care about Linux being written in Rust are the Rust folks, who keep yelling at Linux. The kernel maintainers aren't interested, and the Linux Foundation also doesn't care about it since they keep reducing spending for Linux overall. Linus himself also seems to not care anymore.
I think their position is that they don’t specifically *want* rust in the kernel, they’re just willing to consider it if there’s a sufficiently compelling reason. I haven’t met many people who want rust in the kernel, but also haven’t met many who *don’t* want rust in the kernel
Rust folks are toxic, and Rust is probably the most overrated language ever. I am both Rust/C++ dev, and although I do enjoy Rust tools, I enjoy C++ way way more.
No, funniest thing is you.
It is easy not to care if you if you have no clue whats going on.
@@Zuftware if you claim there is something behind the scenes, why not share the clue? We don’t know what you’re talking about if you keep yelling about it like Rust folks
Did you not see that a lot of the graphics drivers are being written in Rust?
I don't know, all the dependents already break when a core API changes. Sometimes, the one making the change is also the one maintaining the dependency (driver, FS, whatever). In this case, Cristoph doesn't want to maintain the Rust depending on DMA. Well, just post your patches on DMA and cc the maintainers on the Rust consuming them???
I agree with Linus. This should be dry and technical to the point nobody would bother reading it on the socials media. Now the well is poisoned. I wouldn’t bring it up again for a year.
I don’t know because I don’t put my time into it and probably should lol. No idea, no opinion. I can see potential issues both ways. My gut would say don’t add another language unless it is for a separate area ie backend frontend.
100% of maintainers can be used currently.
Would this mean less?
He literally sabotaged himself. Christoph's stance was ostensibly dickish, but the damage Hector tried to inflict is the exact type of stuff to avoid....
@@DingleFlopHonestly, I don't even think the COC comment was the line Hector crossed. It was just Hector bashing on the Linux community and contribution process, which was unnecessary.
I wonder if Linus was dry and technical when he banned Russian developers from working on the Kernel just to comply with US regulations when the Linux kernel development should have nothing to do with geo-political issues.
The talk about shiny language of the day and the patch being a cancer that spreads over Linux was when tech talk ended. There would've been ways to make those points without belittling the work they were doing.
C dev are going be around longer than you and me lol,
at 41:16 you might have stumbled upon a video idea. tier list of the most important softwares ever
I don't know if it was editing or if you skipped it, but you missed another reply by Linus, a couple by Greg, and one from Ted. Ted basically said what you did about the maintainers not wanting to add things to the kernel unless they know people won't go away and that this has also happened with major C things like KVM support. He said that if people stick around and contribute more generally outside of their own directory and project they'll get further.
Ted also specifically asked for upstream Rust to get to the point where the features needed to build Linux were in the main compiler and not considered "unstable" features, and to where there was a gcc frontend capable of building the kernel and not just the clang one. (Because the tooling to build with gcc and rustc is a point of friction.)
Then one of the Rust guys popped in and said, I generally agree with this, but we have people who maintain multiple C drivers, have maintained them for 10+ years, and they want to use Rust for new driver code. So I don't see why *they* should be having their patches denied because otherwise we are just not going to have support for certain hardware and it will either be a major PITA for downstream having to apply their patches or a PITA for users because Linux distros don't like to offer configs with non-Linus repos. So as a practical matter things need to be in tree and hence go through the maintainers.
There was also a discussion of why a fork isn't practical in general: the *relevant* people are maintaining other things in C code too. And the costs are too high. Even major feature initiatives fail when written in C because of current policies by some maintainers.
That part of the discussion was more productive then some of the 'drama' / 'frustration' that made it into your final edited version form YT.
Regardless, it's a hard problem. I don't know the solution. But, I generally agree with Ted's technical argument: Until the Rust tools needed to build the kernel are considered "stable" by the upstream compiler and the language as a whole is reliable enough to support multiple compiler backends (I.e. it at least has a gcc version as well as the clang one), then Rust code shouldn't be merging an official API into parts of the kernel where that upstream breakage can propagate. In the mean time, a bit of per driver duplication may be frustrating, but it isn't the end of the world.
That said, I don't know enough about the build process to know if his argument is sound. Maybe the process is such that you can just turn the Rust stuff off if it breaks the ability to compile a build. Or perhaps the solution is to have a separate Rust driver interface maintainer who can be pulled from separately and who is responsible for maintaining that part of the code and making sure that Rust drivers work in general, that the build tools for Rust stay working, and so forth. Perhaps the wrong maintainers are being given the responsibility of handling it.
Regardless, I'm very sympathetic to Ted's argument because similar considerations keep Rust from being used in a lot of projects (outside of big tech) where there just aren't the resources to deal with these kinds of shortcomings. And as much as I like the language, no matter where you are on the internet, you get backlash from Rust advocates who cannot accept that the language isn't "ready" for some use cases. Plenty of smart Rust people may be working on something, but if you point out that things still need work, Rust fans who don't even work in that field will get upset.
RT_Preempt took almost a decade. So, this will probably be similarly slow. But it does seem like a lot of "the regulars" have a general sense of a long timeline that they want, and other long-time people feel like this is leading to bad technical decisions in the interim. And then there are a lot of other people who keep clogging up that conversation with the kinds of things that made up most of that thread even though they aren't the old hands who are familiar with the process and the people.
Did they end up solving the architectural problem in some way?
@@falsemcnuggethope which problem are you talking about? Video and thread kinda blending together at this point.
@@MaxHaydenChiz did they find a way to not duplicate the bindings in every driver without also cluttering the codebase in the way Christoph was concerned about?
@@falsemcnuggethope not as of the last time I read the thread. TBH, it's not clear to me how big of a problem this is. There's a big difference between 5 drivers and 50, especially if those handful of drivers are concentrated in a couple of manufacturer's hardware.
I love rust as a language and whenever i start a new project, I choose rust as my default. However, introducing it to an existing codebase like this seems like a massive pain and I definitely wouldn't want to be the one trying to fight to get it in, even though I for sure see the value in it
Never mix languages in a codebase.
Don’t even mix related languages.
Replace developers before replacing languages. If a developer wants a new language, cut of his write access.
Mixed language codebases is a cancer.
You want a new language, put it into a new project. That’s separate from the main project. And treat it as it’s separate project. With NO cross debugging between the two.
A separate project is worse. Now you have to re-invent everything between projects and cannot reuse. If you're going to use multiple languages ensure the bindings are seamless so you can still work effectively without duplicate effort.
Amen to that!
But that's the problem: Linux needs the Rust devs. People like you and this maintainer forget why there's Rust in the Linux kernel to begin with. It's because big and very important driver maintainers will not write their extremely complex and critical drivers in C for no good reason. I mean, this is literally about whether the Linux kernel will get good support for nvidia graphics cards, or whether it will always be stuck as a toy. This is also a main question about "The linux desktop."
I would not agree on the related languages part.
We moved a pure javascript project to typescript over time and we found countless bugs just by converting it.
This added the complexity of strict types while removing the complexity of having to guess all the time what type something is and thus saved a lot of time and also helped us to find countless bugs.
So on the front of "Dont mix related languages", i think it really depends on the languages itself.
Epistolary format is honestly so good for reaction videos. I really liked this one! 🥳
15:25 this is why I assume that nobody knows how to properly use semvar and that every change is a breaking change. Because nobody knows how to properly use semvar and every change COULD be a breaking change.
Adding a second language to the kernel is the death of Linux mid-term. Terrible, terrible decision. Maintaining a project with two different languages is a massive PITA which will discourage any maintainer long-term. Not to forget that Rust is indeed the last shiny tool and might very well be replaced by something else a few years from now.
Not, adding a safe low level language is very good. It makes adding new complex features easier and safe. Google Funchia is an example of an OS where c and rust are being used, the old c code is left there, some of it is rewritten to rust, and the new code is created in rust
I love reading books where half of it is written in french and the other half written in german
One thing to think about in the DMA aspect is if there is a ABI/interop issue between the Rust and C putting it in the kernel would crash the kernel vs in the driver it would only crash the driver. Theoretically no ABI/interop changes should get filtered before release but it is technically extra risk.
only a js bootcamp junior would say that c devs will eventually die off lmao
C is becoming more popular now if anything
Would LOVE to see the Rust community policing themseves
Mixing LLVM and GCC compilers honestly is the biggest issue for the linux kernel. That's before working on language compatibility.
Tbh there's two mitigations
A) the explicitly allowed rust code is mostly optional. It's all supposed to be in driver modules
B) gcc is getting a rust frontend
I wonder how well it would go for rusties if they decided to work on BSDs instead
It's possible to believe something needs to happen, but also recognize that it has negatives as well. Everything is a tradeoff. Corporate sponsorship, specifically.
I didn't realize LSPs were so new. Java was doing it since about 2006, at least. Grep-ability sounds justifiable.
Lsp is a specific protocol created by Microsoft in 2015. What you are thinking of is some kind of autocomplete. Implementations of that autocomplete varied from place to place. It used to be that only large IDEs targeted at specific languages could provide (smart) autocomplete.
Consistency is also good for mass search and replace, not just grep.
Auto complete is not LSP.
Before LSP every tool has to implement their own way of autocompletion. LSP is just a protocol that facilitates rhe decoupling of completion engine(language server) and completion interface(editor front end that shows and selects candidates). Which in turn enabling the widespread adoption of autocomplete functionality in editors.
LSP standard is only 10 years old, but features like "Goto Definition" were in Eclipse 20 years ago.
21:56 if it's just a rust layer to abstract DMA (C code) for rust drivers, why is it even an issue? Hellwig won't have to fix nor interact with it.
I don't get it
His issue is that the last time Rust broke the kernel the C devs had to hold off on patches until it was fixed. It’s a straightforward once burned twice shy situation where Hector/Asahi has burned his credibility.
They're just *saying *that Hellwig won't need to deal with it, but there's no reason for Hellwig to believe thats going to always be true. I can think of countless times where another team has told me: "We'll deal with it, it won't be your issue", and it indeed did become my issue. You can plausibly be afraid that it will become your issue in some way, and its happened before on the Linux project. They can say all they want: "It'll just be us maintaining it", but a very valid objection is: I don't want to rely on you to maintain it, I want everybody here to be able to maintain it.
This is a very good point which Prime skipped but it's there in LKML and make us understand why the pushback from C devs coz the point about them not having to deal anything with Rust is a lie.
The C devs did receive a lot of pain. PRs got rejected because of failed Rust build in the kernel.
It sounds like if a C dev changes a C interface, that requires some changes in the Rust code to mirror the change as well or the rust will not compile. This breaks anything Rust related and possibly the whole Linux compilation as they are connected.
This results in a situation that either the C devs have to also change the Rust code to mirror the API, or they merge broken code which is not ideal.
I don't know really anything about the subject, just what I gathered from the vid.
@@pietraderdetective8953 > The C devs did receive a lot of pain. PRs got rejected because of failed Rust build in the kernel.
Yea makes sense, but wouldn't that be the case for any C driver using core code ?
When core code is updated, it's can break any upstream project no matter what language it's using.
Am i missing something ?
About grep versus language servers. I use grep most of the time, because to put it simply, it works with any language in any environment. Setting up an LSP for a C++ project which is built to make setting up the LSP easy, thats fine, but if I get a random C or C++ codebase, I don't even try to use an LSP, because to set it up you first have to understand the full buildsystem.
Even more so, a LSP that only works 90% of the time, can be worse than no LSP at all, because being bombarded with wrong errors, autocomplete screwing around and stuff like that is much worse than having just a dumb editor. Trying to be smart on limited information is worse than acknowledging you are dumb.
That said, when I build my own project and choose my own tooling, I'm using an LSP.
Imagine some idiot who just started programming thinking Rust is better than C when they have barely written any significant amount of code of consequence! If Rust is sooooo good, why don't this Rust fanatics just write their own OS in Rust then instead of trying so hard to put Rust in C?
All the people calling it gatekeeping or "anti-rust" don't seem to understand that this would increasing the supported API footprint substantially, in a way that complicates back-compat concerns, etc. You don't really internalize that until you've had to deal with it.
I had goto definition in Borland Turbo C in 1988. Sadly I haven’t really liked an IDE since that one. I also still regularly use grep.
breaking changes will have to be maintained in both cases whether there is duplicated code in each rust sub component or a top-level shared rust api. Given that rust _is_ accepted it should be done the best possible way (with no duplication). It seems to me there is one objectively better technical solution.
"the Linux situation is crazy"
It is not true that responsibilities will land squarely on the Rust side if they maintain their code.
You still end up with a less coherent system that breaks more easily as a product.
Validation cycles will take longer to prevent this and it will take manpower, even from the C side!
I'm not familiar with these libraries, but every discussion about Rust in the kernel reads to me like someone trying to implement a strategy to replace an existing C component and take over that component, then getting angry when the person maintaining the existing code pushes back.
Also "he used the word cancer *without repercussions*" is a giant red flag. As if everyone must be punished for using a word you don't like.
it's not about the word itself, it's the way a core maintainer chooses to talk about people trying to contribute to the kernel in a way he doesn't like.
@@SmplySilver ywnbaw
To be fair, in this case the Rust wasn't trying to replace anything, and the consensus that has developed is that Rust is an addition, not a replacement.
To be even more fair, the Rust code in this case was a middleware for the DMA api that many Rust drivers would need to use. If many Rust drivers end up writing their own code to consume the DMA api, then changes to the API would break all the drivers instead of the middleware. This change reduces the burden of maintaining Rust.
@@reybontje2375 But introduces Rust on a Core API that is used by everyone. Which I don't think is something reasonable when to compile the rust part you need a specific compiler/compiler configuration. You are forcing everyone to use a specific setup... (That was the "simple tooling" problem they talk about...)
@@framegrace1 That seems to be Linus's position. If you can't just grab gcc and compile the kernel, then Rust isn't ready to be in the Kernel. Someone in the thread was complaining that Linus used a combo of gcc and clang and that's why it didn't build. Well, that's the criteria. It needs to build in all the major tools they use, and that users are likely to use, and it needs to do so reliably. It sounds like Rust doesn't quite have that yet, so it's relegated to a side project and away from the core of the kernel.
Making a deal with a corpo is like a Faustian bargain, the senior devs who lived through Gates and others trying to fuck up Foss know this and are not naive enough to think Corporations do this bc of the goodness of their hearts. Thats just my humble opinion.
Neither do humans(guess what corproations are just bunch of humans witha commonish goal), my opinion is that moat people who work in oss dont do it because of goodness of their hearths but because they get something out of it even if its just fuzzy feelings
And that is why you don't overload version numbers so they attempt to communicate "major change" vs "minor change" information.
Hector sounds impossible to please, and when he isn't pleased, he wants go witch hunting and remove established people from the community who have opinions that oppose his. He acts entitled, literally grand standing and calling the maintainers entitled corporate shills, while literally doing this on donation money. He is paid by the community to deal with the community, it is his job!
Trying to get your way by hitting the other person with a COC violation ls the most "Rust Developer" approach ever.
Seems like a culture I'd rather keep away from anything truly important.
At least this time marcan didn't pretend to be a trans woman, to then accuse an actual trans woman of misgendering...
It's definitely more of a late millennial, gen-z, gen-alpha tactic. Not that older devs wouldn't use it, it's just COC wasn't really a weapon that existed in early software, so older devs don't seem to reach for it as easily.
This isn't how Rust people generally behave, please don't generalize this on the language.
The way he talked to that Rust developer was inexcusable and unprofessional. This is not a reasoned debate it is an irrational and emotional argument.
Rustlets should really spend more time outside of their Mastodon hugboxes and build some thicker skin.
Says soy8739 LOL
Imagine at work and 1 person in the team writes all their code in different language to the rest of the team who are working on an established product .. it would never fly.
I mean, google created go despite having an established product.
@pluto8404 point of correction Go was created at Google, Dart was the official as they wanted to bring an alternative to JS and Java android development, Go had a whole another motive
the linux kernel is not your office's internal codebase
@@bilbo_gamers6417 no it's not. It's far larger, complicated, and more important than that. And if it wouldn't be acceptable in a smaller less important code base, supported by a smaller team .. it follows that scaling any of those metrics just makes the proposal less desirable.
All roads lead to philosophy.
How do you navigate through code without ctags? Doesn't a compiler need to be involved in some way? The only LSPs I've used are hosted and use a database of CTAGS or similar files anyway that come out of a compiler.
I only use LSP and work perfectly
You search for specific terms in raw files its extremly manual and anoying
Prefixes
correct. `ccls` (the main LSP for C/C++) needs a file which lists all the source files in the project and the compile commands. it then reads those to build its own index of your project (using llvm `libclang` under the hood)
10:40 Most communists think that all humans are like clones of one another, so all think and behave alike. The only reasons why there are unequal outcomes according to them is baseless bigotry of racism, sexism, etc.
The older I get, the more I find myself agreeing with the older generations that I used to hate. It feels like at least a portion of the Rust crew -- Hector, in this case -- are really just entitled children trying to use social media to force people to do what they think is best. Every time I see them talk, I lose respect for them more. And I hate that about myself. I miss the times when I could get excited about new technology instead of my first reaction being 'god now I'm going to have to deal with a bunch of zealots trying to force their new religion into everything'.
Zealots - are those c-lovers who for the fear of death can't write memory safe code, and jealous of those who can.
@@Zuftware meds now
When you've had to deal with the fallback of overly enthousiast team members jumping on the latest craze (library/language/whatever) for a while, this is expected. Good tech HAS to prove its good, claims don't matter. It can't be rushed and it has to take time. There's nothing to hate about your perfectly sane first reaction. "Yeah, the demo looks cool. Let's see what the first waves of early devs will say about it twelve months from now..."
43:42 I don't have the words to express the sheer contempt comments like this make me feel...
learn to speak like a professional, retard.
They should just throw out Rust again. It's not worth the drama.
You probably don't know this, but Hector is a legit bad person, and crazy to boot.
I want the old Marcan back from the wii days :(
Using Rust in the kernel is like write a part of the constitution in another language. The readability an standardization in such big and complex projects are a valid technical point.
Your constitution doesn't have an 18th Amendment written in Esperanto?
Greg work for c cause global namespace. But it isn’t really about lsp. The c guys don’t want to look at rust because it makes them want to vomit.
2:00 - I still use grep to search through a codebase. Not purely. But I often do. And the Linux kernel is too large and too complex for an IDE to handle.
So, WW3 was caused by the C vs. Rust drama?
yes
If I can't Find-In-Files or grep for where code is used, may your lawn grow faster every time you mow it.
"Go to definition" is not new.
LSPs are new
Grep'ing code is sometimes more useful than LSP
rust in the kernel is the biggest mistake ever.
it forces all kernel devs to master a language they never had the slightest interest in. and it attracts rustacians, meaning entitled brats who dislike thinking about memory management and believe the borrow checker lets them avoid that - news flash: it does not.
And kernel devs have had to deal with Python and Perl just to build the kernel.
No actually it doesnt force older kernel devs to master new language and it brings in a whole new set of developers who would need to master a programming language just to try and join kernel development yes there will for lomg time be c devs but number will dvindle but kernel needs to keep going
@@bigpod old devs are better and they know codebase better. there is also no point of this overhyped shit language, because you still need to manage memory in drivers, so it defeats the whole point
@@Kerojey relying solely on old devs(old devs are devs who been developing certien codebase for some time) is not a good idea you should always have new devs come into the project, problem is barrier to entry into kernel development is overly high because you need to learn an old(age) language that honestly isnt the best at what it does. So allowing another language into the project isnt abad idea and any amount of technical protections regarding memory are better then no protections, wasnt in kernel around 1000 memory bugs(some security vulnerabilities) just in 2024 alone
Do old devs bring tribal knowledge yes is that a justification to not allow newer ideas into the kernel no
I think kernel has loads to improve its far from perfect in some ways worse then so hated windows kernel. Reality is kernel code should be written in whatever language you want not be gate kept to one archaic language reason for being chosen is because it existed at the time
Having to rely on tribal knowledge and old devs in an increasingly byzantine and endlessly changing kernel with internal apis changing massively between patches is a bad idea for continuing maintenance.
Calling Rust a cancer is pretty clever since the word cancer comes from the Greek word for crab. You could also call rust a blight since rust is named after a fungal plant disease.
linus is the root cause for all of this mess
he is the one who decided to add rust to the linux kernel
he dont mannage what boundries it will have or how to integrate it.
even after multiple drama issues.
Linus was probably forced to do this as well, by US government directives to use memory-safe languages.
@@deth3021That occurred well after and was a recommendation for agencies, not a mandate for projects outside the government.
@@deth3021 that don't e even make sense
@gljames24 you think that someone like Linus and Linux doesn't find out about that sort of action far in advance?
Linus agreed in Oct 2021, the nsa put out a report on the topic in jan 2022,
So it was 3 months after not well after.
Also i never said it was mandated.
However is major goverment contractors who fund the Linux foundation start to put pressure fir what they know will be a long process. You saying it will have no effect?
He's letting his people figure it out, like a good leader should.
23:39 He is right. It's that simple. This is a software engineering issue and that means it involves people. Cross project maintainability is project integrity is project success. Nothing wrong with multiple languages if you have factored it into resourcing -- but it inherently can't be in most open source projects. These must often mutuate past such problems by OS software evolution or rather natural selection - it's called forking.
If rust at the height of the hype is not able to endure at least 5 years of grinding fir a better position on a project that is 30yo, they dont have what it takes, and don't deserve said position.
My hot take.
I don't think that's a hot take, I think that's reality. The kernel runs the world, everything in it's gotta be slow, or at least very deliberate. Jumping into that as a language whose whole thing is announcing that it's both better and drastically different and not expecting there to be years of growing pains seems incredibly unrealistic. Even it the only thing that was happening was migration, forget that there are still mostly C devs who are still very actively working on the kernel.
HOnestly Linux is on a death clock. Atleast this version of it is. Rust is fragile as hell, requiring extensive bindings and just some backwards ass thinking when paired with C languages directly.
Honestly, It would also only take what.... one or two changes to the rust compilers to shatter the drivers as well?
Next the VC fundend JS bros are gonna want javascript in the kernel
Rust is literally more performant than C in many cases.
@@bilbo_gamers6417 Could you name a few please?
Why are they so obsessed getting their Rust into Linux. Gtfo, bork your own OS instead of trying this coup.
Rust in the Linux Kernel is a classic example of Groupthink or "Going to Abilene". Prime lays out an ironclad case here for why this is just a bad idea - an outright stupid idea, even. It blows up the complexity of the project and blows up the accrual rate of technical debt, and subjects the whole thing to blow-ups in production. But a whole bunch of folks are chasing shiny objects without checking their baseline or seeing the bigger picture. Either they need to fork it completely or not at all. As a Linux user, this deeply troubles me because I am already dealing with the spectre of creeping enshittification in so many other areas of my life right now. I hope Linus weighs in heavily on this one and does the right thing, this project needs to last for decades to come.
same thing when people compare the speed of programming languages while completly forgetting the specific use case of it
They should rip Rust out sooner rather than later, before it becomes too entrenched in the kernel. Then make a separate fork that is maintained by Rust devs to port the kernel to Rust. That should make everyone happy, apart from the people who want to force their opinions on others.
@@defeqel6537 Your words to God's (or Linus') ears!
@@defeqel6537 "[...] apart from the people who want to force their opinions on others."
So Rust devs, then?
Which is the reason why even MINIX 3 is more popular than it.
Grep is the generic term for command line search tools. I dig the ability to tailor the search area and control the output. Don't knock it unless you try it!
So some people are coming into a project, that has had a strict standard for development for decades, and they want to insert their shiny new tools in there.
The Linux kernel is not exactly the place to be testing your new language and having to split a project to multiple programming languages is very problematic.
Standards for the sake of standards.
@@Zuftware make your own kernel. otherwise, take and eat shit. you are crawling on your knees to insert a genuinely bad language into a monolith.
I think forking linux for rust folks is the best course of action here. There's no point arguing with people who doesn't see the value of your work. Linux folks have their reasons, and it clearly isn't compatible with what the rust devs want.
Prime, I want to let you know I'm gay.
same (except that I'm too stupid to code in Rust)
So proud of you
Why are you gay?
how can i be gay man if my boyfriend is homophobic
I too code in Rust
And WHY does a small group of developers force rust into Linux?
Is there really an advantage to be gained here?
It sounds like a hobby.
Rust developers are big because it's easier to excel in rust than in safe c. How many bad drivers does linux have? It doesn't even have good nvidia drivers. Rust makes implementing complex features with safe very easy. So code low level complex multi core parallel programs to feel the experience
@@shining_cross From what I seen of rust, anything having to do outside the native language, and even some of that is extremely complicated.
Just simple code where the developer has no full control of the memory layout has some benefits.
To me that looks like an extremely poor fit for OS/driver development. Like, what can be possibly worse? Python maybe.
@@TheEVEInspiration Not, adding a safe low level language is very good. It makes adding new complex features easier and safer. Google Funchia is an example of an OS where c and rust are being used, the old c code is left there, some of it is rewritten to rust, and the new code is created in rust, there are more than 2 million of rust code there
24:21 Even John Carmack has mentioned the disadvantages of mixing two different languages in a single project, it increases complexity and adds friction to development.
Linus is willing to pay that cost in hopes that it will drive in more devs and be a net positive as a whole
@@nocodenoblunder6672 yes, it looks like it, and it's probably a good thing, in another comment I mentioned that it is a great opportunity for rust devs to be able to contribute, but it is going to be a big challenge for both parties to find a middle ground. A lot of patience will be required.
Linux needs hard boundaries. The idea that the entire kernel can be huge and monolithic and endlessly changing internally as one single unit is insane. The fact that api changes break rust is a sign that there are serious issues with kernel development. APIs should Not be constantly changing.
@bilbo_gamers6417 I agree with that, there must be a really good reason for changing an API, even if it's an internal one, and probably they should be a bit more considerate with all the people affected by that. To me, that feels like an intentional move to cause frustration to rust devs.
@@sarok21 Yes! I don't even care about Rust devs, honestly I think maybe having to include Rust can finally force the developers to put stable APIs into the kernel. if the Rust developers part ends up sucking super hard then you have your answer for if Rust should be in the kernel.
Great comment on “being nice even if the other side is not nice”. It can be incredibly frustrating, but being mean to everyone who isn’t nice to you sounds like a miserable life imo.