Amateur Rust user here, nightly (which I have used with embedded programming without issue) is most definitely not what should be used in Kernel development and I want to make that extremely clear. Nightly with rust is more stable than it sounds, Nightly is like the Fedora (which I use) of Linux; leading edge rather than bleeding edge. When Rust gets to the Debian stage, then and only then should it be used for Kernel level stuff. Until then it should stay out of it. I believe that parts of Nginx have been written in Rust so it is at least ready for driver and module stuff, just not core Kernel.
@@corey__wm Its still not ABI stable though and you can't work with it for dynamic linkage which makes it functionally useless for Unix infrastructure in general.
@@Spartan322 Interesting. Last time I asked about that very thing and made statements based upon this assumption people came out of the woodwork to attack and make baseless statements against me.
And what people don't realize is the most important aspect of C is the portability. What language lets you have a compiler on every platform in existence, even the tiniest ones. Are you going to get rust compilers onto all these 8 bit and 16 bit platforms? It is gigantic.
You aren't going to compile the full modern linux kernel to an 8 or 16 bit platform are you? Rust uses LLVM so can target the same platforms as clang. Also you don't need to run the compiler on the target platform.
@@nullid1492 Its also not ABI stable so it doesn't actually have capability to support POSIX kernels and can't support a Unix kernel in the theoretical sense.
@@nullid1492 tell that to dmitry grinberg. he ported it to a 4004. a 4 bit cpu from 1971. and why add complexity when it isn't needed? K.I.S.S. applies. adding rust to that mix just adds nonsense that isn't needed.
Imagine coding in a language that is not internationally standardized by at least two committees and have less than 3 compilers. Literally bleeding edge unfit for production.
@@Bokto1 ThE cOmPiLeR iS tHe SpEc. (But I digress, as a Common Lisp guy we've only got one spec and a handful of real time assembly compilers. But there IS a spec.) The worst thing you can do is tell people the current implementation is the spec. That's terrible and subject to change on a whim of whoever's falling from power at any given month. Don't trust a programming language that's not old enough to vote and doesn't have a spec. Age wise, Rust is still using a sippy cup and doesn't know what it wants to be when it grows up so it tries to be everything. That's exactly how C++ got into the mess that it's in now with complexity and undefined behavior. I estimate that Rust will soon blow past C++ in complexity, syntax, and shaky bridges between disjointed concepts. Perhaps it already has.
@@PixelOutlaw Undefined behavior is defined in spec though. It's relict of C that allows for C to be the most portable language, while remaining as efficient as possible. The issue is Rust is supposed to be this deterministic way of programming, which it clearly is not.
Rust often feels like Soviet Imperialism too, no questioning the great leader type deal, constant purity tests, struggle sessions. The Rust Foundation trying to sue people in violation of the American Constitution pretty clearly demonstrates who its actually aligned with.
Thanks Bryan. Wailing and gnashing of teeth will not change the facts. 1. Rust in Linux is not a matter of life and death and does not have to happen immediately. We have survived without it all this time. What we have now just works. 2. If the narcissistic Rust developers can't wait, then they can build their own kernel. It's not like it has never been done before. We know it is possible.
Nobody cares about another kernel, also still lacks ABI stability so it'll never get POSIX support and it can't support a Unix kernel. Its not even a potential thing, it is theoretically impossible for it as in accordance with Rust language developers and designers, Rust was not really developed with a consideration for the real world and its not the only systems programming language that carries its protections without a GC, its just the one with the most ravenous and easily offended fanbase.
Using the word “…narcissistic…” sounds as if one is an a young American woman who got dumped by Chad and Tyrone because one thought they were a 10 when in reality one is a 2.
@@raidensama1511 we are in a tough position with that word because it is a very real thing, but the people who it actually applies to tend to pick it up and point it at everyone else. Reversals, distractions and word games are some of its core features
As a Rust lover, if it ain't ready, it ain't ready. I want good things, I don't want bad things. It's the entire reason I use Rust in the first place, and it's the reason we shouldn't be using Rust for the kernel yet. Why is the culture of FOSS people so toxic and absurd? We can be better, guys. We can just not be assholes, please. Rust people, please. This is a young language, we have a lot of work ahead of us. C people, please, just document your code. It's not that hard y'all, if we were all nice maybe we wouldn't have a developer shortage.
Oh, screaming gods, you ask for *documentation* of existing code? Yeah, I have seen that road graded before . . . . But I have watched tremendous progress happeni, too; I remember when Ruby was new, and I remember when first "+" and then "++" were added to "C". Good luck takes good people, and you are expressing the right attitude to make it work!
@@jupitersky thank you for being sensible. The pushiness of the rust community is super off-putting. It's not just rust either. Python just "suspended" Tim Peters for crying out loud. And this business with Godot. We need to get the communism out of open source, stat. Let's get back to making software
@@livenotbylies Quite honestly, FOSS is often more dictators and oligarchies. Communism is what Wayland looks like... and uh, let's just say there's a _lot_ of arguing holding basic features back for many years. I believe it is a wider cultural issue with how people behave online, one which has been evolving and changing since the early days of the internet.
@@jupitersky I used the term communism somewhat loosely, but I don't think this is just behavior on the Internet getting worse. There is something afoot. I've been involved for 25 years. Western culture is infected with something right now. Something shifted about 2008 and has been picking up steam. I hope the fever breaks soon
@@livenotbylies Aye, I smell it too. It's definitely not just on the internet, but I believe that's where it originated. Something big is going to go down, but whatever it is hasn't quite taken shape yet. I feel like a paranoid schizophrenic saying this but... it's tangible, you know? Western culture its self is shifting as the older generations fall away and the new ones, born into and raised by technology are forced to reconcile with reality.
File this under "No sh1t, Sherlock." Rusties constantly try to disingenuously compare their nightly build features to 35 year old unstandardized versions of C++, while also completely ignoring the amount of validation work that goes into the latest ISO standards and major implementations of it. Rust doesn't even have a comprehensive published standard.
C++ is a really bad language and needs a replacement. Really really bad. Modern languages like D are slowly becoming wrappers for it. But as more developers get fed up with c++, more people will switch to better alternatives
Requiring nightly builds of a compiler is a no-go for industries that make mission-critical and safety-critical software and require well-tested and certified compilers. In some of those areas, even C++ has trouble to make an incursion into, much to my dismay. The beauty of C is that it hasn't changed in ages, and the ISO C committee is incredibly conservative in making changes to the standard. Rust will never set foot on those industries as long as this culture remains.
Quick correction it is not using nightly builds of the compiler it is using stable releases but nightly features. Rust has a certified compiler. The beauty of C is that the kernel is not using normal C and you need an LLVM compiler from 2022 to build the kernel. Yet adding another language needs a compiler in stable today when it took the next largest C compiler ~10 years to be able to compile the kernel. They are setting things up to fall into stable builds and it looks like they on track to beat LLVMs time which feels crazy.
Good news. I was baffled by the idea of mixing a foreign language into the kernel. C and ASM. That's it. But rust fappers are on the wagon to make us all "happier". PS. To Miguel Ojeda: My flexibility ends with erected middle finger.
Capturing Linux didn't work the usual corporate ways, so now MS et. al. build support for and code a trojan horse component. Gee, didn't the xz project try something similar?
It's right in the name and the logo, they put right in your face. Rust. That's iron oxide, produced by the oxidation of iron. They're rusting away the existing support structure. The logo is a crab. That's the sign of cancer. Rust spreads like a cancer. Crabs, ie crustaceans, arachnids, and so on, don't use iron for oxygen transport. They're blue blooded, ie they use a copper compound, hemocyanin, not hemoglobin. You can also count the number of teeth they put on the R gear, and the five holes surrounding. R either refers to 18 or 9, so look at the 18th or 9th pentagonal number. Contrast it to the number of teeth on the gear, which is 32 to my recollection. It's all right there. A copper based blue blooded creature, the sign of cancer, is rusting away the existing infrastructure and replacing it.
@@etherweb6796 Yeah, they did. All of that, + the aggressive cult-like and quasi-militant approach to engulfing other projects, with the odd corporate backing, all told me something was up. It's unfolding a lot more clearly now. The other thng is the "Crate" concept and the build / package management tool "cargo". A reference to a cargo cult. Lot of little things that may at first appear tongue in cheek, ironic, or self deprecating. Even humorous, a parody. When that's the kind of doublethink environment they're going for, and they actually mean what they say.
@@Acetyl53It's like listening to a freemason smirking while claiming "it's not a religion". Spoiler alert: It's a religion. And it cannot withstand sunlight.
It's about the money. They take money from Microsoft, Google, etc. to push rust adoption. Microsoft hopes that rust will sabotage the kernel development, the linux guys think that they can take money and sabotage the sabotage.
I'm the person who posted that to Reddit, which is where I'm guessing you found it bc you uploaded this the next day. I don't agree with you ideologically or philosophically, and in fact I don't have a problem with Rust in the kernel per se. The reason I posted that is because I felt like some disclosure was in order regarding the big tech forces pushing Rust in the kernel bc people say things like, well Linus wants it in there. But to me it was very clear there were powerful forces working behind the scenes that were pushing for it, and my suspicions were confirmed by what Ojeda said. And as someone who values libre software, and given the history of those specific big tech corporations violating the GPL and other treatment towards libre software, it did certainly pique my interest and I felt like a public service announcement was necessary.
> the big tech forces pushing Rust in the kernel That's exactly why anyone and everyone should be avoiding it. I haven't seen anything good in standards pushed by big tech in 'recent' years. By recent I mean all I remember.
While it would be insane to rewrite project X in language Y that it wasn't already written in, a completely new project using language Y might make some sense. Towards that end, it would be really cool if someone implemented the entire feature set of QB4.5 for modern PC's, but upgraded of course, and then wrote a completely from scratch kernel as a project. I know some people would point towards FreeBASIC, but that wouldn't have the same cool factor as using QuickBASIC.
Here I was thinking they had crossed their T's and dotted their I's for the amount of noise they make about putting this thing into a production operating system kernel. Good god,
Oh we dotted our i's and crossed our t's... _by listing the stuff we can't do yet lmao_ If only programmers would stop being so fanatical about stuff, then we might be able to get stuff done. Wild stuff, truly wild stuff.
Oh god. the weirdos that post on every channel that so much as mentions Rust will now brigade this comments section. The worst are the ones that have Rust in their username. shudder.
Rust is probably the most toxic developmental community I've ever seen, I don't think I've ever experienced a worse set of human beings who all associate with each other personally in my life.
Rust is great, and I agree that eventually it would be great to have a kernel built from scratch in rust. But I wouldn't push into linux unnecessarily. If the C devs want to use parts of Rust voluntarily, I would assume even stable is usable for some things, but there is no reason to bend over backwards to push it in. There are really shady smelly influences when I see rust being pushed that un-naturally
thats ok rust enthusiasts ; maybe another 50 years rust can have the similar quality level of support, tools and reference material that c had 30 years ago
@@arkeynserhayn8370oh man, I pointed these very facts out in a similar TH-cam video and the level of butthurt it raised was unreal. even hint that it's an immature language and you can snell the unwashed nerds dander ruffling up through the responses
@@RenderingUser Formal specification in which syntax is defined. It's not about how a language is strict, it is about having a formally-defined parsing-consistent syntax. Fun fact: JavaScript while being dynamically typed is syntatically consistent. TypeScript while being more stric type-wise has a parse-inconsistent syntax.
I really had high hopes for rust, then lost it but thought "okay, for a kernel its probably fine" - then lost it... I feel rust is NOT "the language" - more like an evolution step that moved waves on the water so real "the language" can come - actully started working on one...
@@arkeynserhayn8370 It's called BASED. It has no borrow checker but a system based on semantics and syntax which is much simpler yet handles 90% of cases (and its clear which case it does not). No GC. No OOP. Also has pretty heavy metaprogramming because the compiler is fully scriptable (but its not like Zig comptime so its an other language which is somewhere between FORTH and C). There is also a very new system for generative programming that I never have seen anywhere before and makes writing stuff much easier in my opinion. Very closed for now. Will be open source if I find it is stable enough. In this I follow the "Cathedral" and not the "Bazaar" style. I think for a language the Cathedral style and having conceptual integrity is really needed.
@@u9vata Once you fully docmented all the formation ideas of your lang, learn about ATS, a ML-like systems programming language with strong support for generative programming; it implements type-level proofs and linearity checking for correctness. I said dont look at it because i dont want repetition of ideas, i want people who design PLs to come with raw and new ideas, and implement them in POC languages with weak developer dynamics. If you feel like it, replay to me once it went public.
It's not just the stable rust release. Its the stock distro must support it. If i can't download the kernel and build it without jumping through hoops to get packages from outside of my distro, the process is broken. This isn't even a "kernel developer" problem, it's a package maintainer problem, a "i like custom kernel builds" problem, etc.
Yes? That's kinda the point of a "stable" branch; to be outdated and not have new features. Gotta be honest this feels a bit like a manufactured story. "New endeavour requires tooling not already developed!" isn't exactly breaking news, that's kinda how things being 'new' works. If I buy a 5090 and it doesn't work well because I'm using Debian stable LTS, that doesn't mean either debian is bad distro or that the 5090 is a bad card, it means I'm being an idiot and trying to use brand new hardware with a "stable" (see : slow) OS. In other news, use of hammers called into question after recent study revealed that using them to break lightbulbs will lead to some lightbulbs no longer functioning properly. More at 7. This weird desire people have to act like Rust devs are somehow "forcing" Rust into the kernel just because it's new and shiny has always fascinated me. Well, maybe not "fascinated" but its certainly a strange case of confirmation bias. Linus hinself still gets the final say on what is/isn't allowed in the kernel, and he is about as antithetical to "ooh shiny" as I can imagine a (vaguely rational) person getting. If any single person on the planet alive today was most qualified to say what is/isn't suitable for kernel level development, it'd be the guy who literally invented the kernel that the entire world runs on, and it's in there under his whims, so acting like its somehow being "forced in" requires a geuinely intriguing level of either confirmation bias and/or straight up delusion.
I think the issue is that not only do you have to use the unstable nightly build, but that even that build is not capable of doing the work needed. Currently the nightly build is only capable of doing certain parts of the kernel. So, while you may want to do this, and it may be the correct thing to do. Pushing it now, when it is not capable of doing the job, and the only way you can even get it to do small parts of the job is to use nightly builds is dumb. Develop the language until it is at least capable of developing for the Kernel before mandating it.
As someone with an anime profile picture, please continue making fun of furries, mastodon users, and Rust software developers. We will not claim them as one of our own. They're punishable for stolen valor.
I might crucified for this, but: If I were to add a new language to the linux kernel, would be C++. Makes more sense and it has proven to be solid over the years.
To be fair, Rust is stable enough to write a kernel from scratch. It's not stable enough to work with extensively alongside C. If you wanted to implement Linux in pure Rust you absolutely could, the problem lies in integrating with the existing codebase
Then why don't those people go work on the Redox project? It's a linux compatible kernel fully in Rust. Writing a kernel from scratch directly in Rust should be better for them.
And while whole world is depending on existing code, I can understand that this doesn't happen fast. As far as I know, Rust code will run something like 1,04x slower than C, and language itself is not as stable while last version of C was 2011, I don't think Rust is the right tool for the job. I believe that instead of using Rust, formally verified C is better route or even write domain specific language for the job.
@@gruntaxeman3740When Linux started nothing was stable. Linux still survived. Rust is quite mature. Interop with C might have room for improvement. Using it will show where it needs more work. In software there are 2 states. Old, stable and unflexibel vs new, less stable and innovative. Your stance will just lead to death. Rust can rejuvenate Linux.
I started on GWBasic -> Quick Basic -> Quick Pascal -> Quick C (The first 3 were taught in my highschool) and honestly once I got to C, I never understood why anyone would waste their time with basic or pascal, they seemed utterly pointless. Generally the argument was that it makes teaching the basics of programming easier, but the kind of things you program while learning are simple regardless. If I were going to teach a beginner programming class I feel like you're better off starting with basic examples in assembler and work up from there. Learn the truth, not worthless abstractions.
@@entelin I hate to tell you but many a Quick Basic programmer made bank writing shareware apps back in the DOS days. I saw one grad student write a wind tunnel control program with Quick Basic that probably would have taken him months longer in C. Also, many programmers who learned in Quick Basic graduated into the MS Visual Basic system and had careers in software development. So, worthless? Not at all.
It never mattered if Rust was ready or not, the only thing that mattered to the people pushing for its inclusion in the kernel 2 years ago was to full fill the religion goals, just like some other projects take it to the point where they weaponize the dependencies and take over a project. Mark my words, if you give them a hand, they will take your whole project and eventually kick you out for not adhering to their religion or their code of conduct.
For sure. One obvious point is indeed that if there are enough Rust devs in the Linux project, their "code of conduct" will prevail and Linus absolutely doesn't fit it. So he would get kicked out one way or another, and I'm sure that's their goal.
You need to be able to compile the most recent Linux kernel with the Rust packages that are in the standard repository of the oldest still supported Ubuntu system. E.g. Ubuntu 20.04 (Long Term Support Release) currently includes rust-1.80. If the first Rust version capable of being used for the Linux kernel is the one that ships with Ubuntu 24.04, then Rust can be used for Linux development beginning in the year 2027, when Ubuntu 22.04 goes out of LTS.
หลายเดือนก่อน +1
No such Rust version in 24.04… 26.04 at the earliest. And that's still doubtful at this point.
Common practice is to be compatible with all current and previous production OS. Currently: -Debian 11 and 12 -Red Hat Enterprise 8 and 9 -Suse Enterprise 12 and 15 -Ubuntu 22.04 and 24.04 etc. Suse 12 is however in extended support so may be that doesn't matter so much.
Rust is coming close to its 10th birthday here, and it's "too soon to ask the Rust community for a completely stable compiler to build kernel code with". I struggle to see how Rust devs expect anyone to take their language seriously if building a stable compiler within 10 years is too much to ask of them.
@@exotericidymnic3530 Clueless deluxe lol. I said RFL. The Linux kernel requires new features that the compiler did not have. Those features were developed 2-3 years ago. The compiler is stable. Yall misinformed on everything lmao
@@exotericidymnic3530 Holee the amount of ignorance lmao. RFL means bindings for a 2nd language. There is no port. There are specific features that the kernel needs that the Rust compiler did not have. How hard is that to understand?
I think zig would be a better fit for getting a new language into the kernel along C. Yes, zig is not 1.0 yet, but if they start focusing now on getting zig into the kernel, by the time it will reach 1.0 it will be stable for linux too. And that might even be before rust gets all that list done. Frankly, I think that when rust will get that list done, irrelevant of the time-line, the language will be so complex that no-one will want to use it.
No, it's just other programmers who hate (or simply are not qualified enough) to think about what they do in a program, so they need a compiler to rely on in every way possible.
Not every design decision requires absolute stringency. It's the equivalent of always checking bounds or always checking for a null pointer in internal code where the checks had already happened upon entrance to the library and no longer need the checks. Unfortunately, most compilers aren't capable of detecting when it isn't needed in heavily nested code and still require a programmer to know what they're doing and think about it properly and thus to give hints to the compiler.
@@RomanAvdeevX And every year's been the year of C since. Nothing dethrones it. You have C and you have C++ and everything else wishes it could dominate
I swear they are like webdevs by daylight who want to do something systems development/electrical engineering but they dont want to touch microcontrollers.
As a Rust user myself who uses Linux, I have to agree. If meritocracy says that it can be apart of the kernel, then and only then will I be okay with it being there. It is easier syntactically to read, however, if it isn't ready then keep it out. Innovation can be a cruel mistress, we shall see how Rust fairs in a decade or so within the kernel.
@@corey__wm Rust should stay out of a monolithic c-written kernel. People who want to do systems development in rust specifically, should work on their on kernel with a toolchain that suits their preferred language, not shoehorn it into existing projects. Rust is fairly okay for business logic applications tho, nothing groundbreaking, but not bad either. It has it's tradeoffs.
Rust seems to be a magnet for software holy wars. If the language is presently too half-baked to implement what is needed, it probably shouldn't be a priority unless they're putting resources into implementing the language.
It could be that it's necessary because Rust wants to get into an area that was covered almost 100% by C and many C developers are comfortable with that and resist change. Breaking up monopoly doesn't happen by itself.
Pretty sure there was some kind of national security announcement a while back advising everyone to write code in Rust. There’s a lot of industry push.
That whitepaper advised people to write code in memory-safe languages, not just Rust. For all that matters, we could start writing code in a more mature and stable language like Ada. But people default to Rust because they all want to jump on the bandwagon of the latest, greatest hype.
@@TawaraboshiGenba That paper seemed a bit political and unnecessary, rather than a truely useful technical advisory for experts. Like the agency employee that wrote it is probably a rust fanatic just looking to undermine the alternatives. Not that it promoted Rust specifically (that would be too obvious), but its focus on an outdated misrepresentation of C++ (Rust is really trying to be C++, not C), and in that that whoever wrote it seems to lack the basic knowledge of languages standards, compilers, validation, and computer engineering to know the structural difference in execution between Python, Fortran, or Java. Like yeah I'' just go write this driver in Javascript and glue it in with some C#…
@@RustIsWinning Are you a troll or do you sincerely want to know what's good about Ada? Ada has much better safety guarantees than Rust and it is battle tested language which is used in avionics for example, where high reliability is very important. Is it enough of explanation? If you want to learn more just google "Ada SPARK" or "Ada Ravenscar profile".
@@RustIsWinning Do you sincerely want to know? Ada has very strict type system and provides better safety and reliability guarantees than Rust. Is it enough of an answer?
@@AleksyGrabovskiYes that's why I said please. So Ada requires spark? Is that an extension? Also how come that it isn't popular? Could it be because it doesn't look like C?
@@RustIsWinning SPARK is a subset of Ada. If you want even more safety guarantees you can use, so called "Ravenscar Profile" it will make it impossible to compile a multithreaded program with a deadlock, but it is difficult to program, because of different restrictions. So basically you select different level of guarantees depending on a problem. For example multimedia application doesn't need to be very robust and you can program it in full Ada, but if you want to write a microcontroller for a drone then you might want to have the strictest possible subset. And why isn't it popular? I don't know. Popularity doesn't always reflect quality. I think Ada doesn't have good marketing.
I think you'd have to take it point by point... If someone said, hey rust is having problems because you have a double free here and the maintainer replies with "I hate rust and that code has been stable for decades." It's not really an issue with rust that the current C code doesn't work with it.
If I had to choose between someone using floppy discs and someone using the next thing after USB pen drives to believe in deciding how things should operate... the guy and his floppy disks can kick rocks.
@@cheako91155 They can and do produce ABI stable binaries (something Rust can't do) and they can produce compatible ABI stability on the same architecture and platforms, C is capable to do this where as Rust cannot. All usable C standard libraries are legacy stable, Rust also does not have this, it is incapable of doing this.
@@Spartan322 no, the kernel checks modules b4 they are loaded and if the compiler versions don't match the load fails... not only are there compatibility problems, compatibility is expressly forbidden.
It should be noted that if Linus thinks that parts of the kernel need to be fixed, there's a decent chance that maybe it was a bad design in the first place that only survives because it already exists.
I remember having problems with a buggy C++ compiler once. So I switched to a different compiler vendor. All Linux has to do is choose from the many different rust compilers that meet the Rust language standard. Hmm, I guess those don't exist. Doesn't seem like a great language to adopt for a long-term project.
If two stable and mature compilers existed across most architectures like is available for C or C++ a lot of the objections would go away. But there are still issues beyond that.
Not a dev, just a plebeian normie here. I was genuinely excited to hear about rust. But in the end I just want an OS with a working kernel. I don't care what lang, just a working kernel.
Time does not guarantee a piece of code is "battle tested". Tests guarantee that a piece of code is tested. Just take a look at your other video related to the CUPS CVE with a 9.9 score. Even the unstable rust compiler has lots of tests to make sure it does what it says on the tin. You're contradicting yourself, why is CUPS not "battle tested"?
The Linux project allowing another language besides C is a big deal. The only reason they would allow the possibility of adoption of another language (let alone far from ready with working well with integration with the existing kernel) would mean it would have to have such a compelling set of features that improves the quality of the kernel. Rust does a great job of modeling systems-level code with less and aiming to be zero undefined behavior and better tool-able to build safe systems. Don't get me wrong, C is a great low-level language and can currently do things that Rust cannot, but it has a lot of problems with being early to market. I do hate all the drama with Rust and both sides need more empthany for each other. C and Rust developers are very different. C developers aren't being helpful commenting about how Rust developers dress and their personal lives and Rust developers should be more tolerant of those who made a world class operating system, these guys built the best open source project without tooling telling them it's safe or unsafe to do so, that's just bad ass, and they have a lot to learn about those that shipped something so grand and so heavily used it blows my mind. That said, this video feels like a lot of FUD. No idea if this will work out, but Linux was created because someone said how hard could it be. How about you let others try, learn, and explore and stop talking about how pathetic their first attempt is. We were all there at one point in our lives where we have big ambitions and bit more than we could chew. I think a more productive path would be to set reasonable boundaries and otherwise let the experiment continue, with the goal of learning with a stretch goal of this might actually work.
This ^^^^, Another thing to keep in mind is the Linux kernel required and in some cases built custom extensions in GCC to actually compile and function properly. It's natural and expected that a big new use case for the language will expose the need for new feature and where existing features need cleaned up or fixed. And it's not the sort of integration that will get easier as time goes on. The projects need to hold hands and work closely together to avoid devolving into a total mess. Integrating any new language into the kernel was bound to be hard, but Rust offers significant reliability and safety features, plays well with C and is reasonably stable. Zig isn't anywhere close to as stable, C++/D offers few advantages for the headache, ada has runtime assumptions that don't play well with the kernel, haskell is inscrutable and has garbage collection.
The sense I got about extensions to the gcc compiler was it was more focused on getting it to work where Rust seems to build out features properly and general purpose and that takes time to stabilize. I see great potential in Rust but people need to learn to get along on both sides.
There are good reasons to hate C, but no reason to replace it. C's so great because it's the standard. Rust will never be because it's so complex and doesn't fulfill any of the roles in the ecosystem that C really does.
Back to the drawing board until it's done! Languages that are not embarrassing (that's you, Python) are hard. Pleasant languages are harder. Does Rust have some wins under its belt yet?
@@RenderingUser None of them are ABI stable, so none of them are non-Rust usable libraries, they're all all end user programs or Rust-supporting libraries, no Rust library exists that can be used as a binding for other languages while maintaining the stability of C, that makes it useless for Unix infrastructure, and the Rust language devs refuse to cooperate on this, its so far considered theoritically impossible to accomplish this.
@@RenderingUser You can't rely on Rust in a library fashion like you can with C for anything that isn't compiled by a Rust compiler, the lack of a stable ABI means that it does not make any promise for dynamic linkage.
For my last 2 employers, I'm programmed in Rust and Go. Maybe I'll go back to BCPL.
หลายเดือนก่อน +3
You're right about PERL... though still useful... but it's like slitting your wrists while doing sth. productive. Rust can improve the kernel a lot. But it has that one tiny hurdle, that it has to overcome. ("tiny") And while Torvalds has some controversial opinions, he's right on this one. Cat-ears or not. Rust is great for kernel development, but it has to have a stable toolchain.
"Rust can improve the kernel a lot." xD Adding new languages to a code base is like taking immigrants in. 99% of countries on this planet were founded by one ethnic group of people. I don't get the idea of breaking a code with language THEY/THEM DIVERSITY.
@@hadeseye2297 while I get where you are coming from and I agree mostly with it but not absolutely. I cannot take the NPC profile picture seriously 😂. Anyway, have a good rest of the week.
หลายเดือนก่อน +2
@@CommanderRiker0 "BUT RUST FORCES MEMORY SAFETY!" Unless you use it in a kernel, where in many parts you have to dick around on the bare metal (which many folks don't understand: the C in an OS kernel isn't the C you write for an app) and that very often requires being "unsafe".
Compilers are to assembly what Copilot is to JavaScript
หลายเดือนก่อน +6
Rust must land in the kernel because that's credibility and visibility that Rust needs to spread. As they say and you quoted, it's a Flagship (capital F) project. Just like git won at least in large part because of being used for the Linux Kernel, so they hope it will work for Rust. Also, looking at this I remember discussions around DRM/DRI back in the early 2000s, and how much difficulty the DRI devs had with Linus (reasonable reasons, I need to add) about a new API being accepted. Or the barrier for new modules new drivers… Rust had it *WAY* easier. Thanks, I'd say, to pressure from Google, Microsoft etc. And another thing: Rust brings memory safety, right? But that's largely it, to my understanding. Now, I'm not discounting the problem of buffer over/underflows and related problems. But that's not the only source of vulnerabilities. Just for example, how would Rust have helped (tangentially, I admit) with the CUPS exploit that just came out? Answer: it wouldn't. Another one: Apple GPU kernel driver is being written in Rust. And the pressure of getting that, when finished, into the kernel will be *very* high. EDIT: Or maybe not. I forgot, in a moment of weakness, how few people run Linux on Mac hardware.
I remember that time I wanted a stable, simple OS at work, so I installed Debian. Hadn't run Debian since the day debootstrap output stopped fitting on my USB drive. Running update-initramfs on a virgin installation would break the OS. Kernel panics preventing boot up. Ended up installing DragonflyBSD instead. Have considered Debian to be too unstable for production use since circa 2014. And too fat for minimal systems since circa 2010. Ironically, the Kali installations are at least that old, so we consider Kali to be stable enough for some production use (but not Debian) Oh jeez I miss quick basic. I used to write sorting algorithm visualizations in it. Nowadays there are dedicated yt channels for that
@@gruntaxeman3740 my USB is 64 MB. It's my first USB. I still use it as a boot medium in my cluster. Just can't fit Debian anymore. Since the system ramboots and runs on very old hardware, this was a deal breaker. I remember the day that happened because that was the day the Finux stopped running Debian. As far as messing something up... Do a normal installation with default options, sudo apt update, sudo reboot, then kernel panic. By my standards, that's not suitable for production use. Maybe they fixed the bug since 2014. I wouldn't know. I switched to distros that don't have that problem. In other news, one of my Kali laptops finally expired this year. It was installed in 2007. I use that as a litmus test for stability: if your distro can't do that, then it's objectively less stable than Kali Linux -- or backtrack, I suppose
@@innovationsanonymous8841 Cheapest USB sticks what we bought to give free for our customers 12 years ago were 2048Mb. They were like pencils with company logo or business card. And when we are talking production use, something like used in hospital or logistics. We are not talking some garbage found from landfill. Looks like you haven't seen real production system in your life. Cheapest virtual machine today that is available has 1Gb RAM and 10Gb storage. Your issues are likely related to computer found from landfill, not OS.
@@gruntaxeman3740 I think he's got a point here. If it still works, it's still valid. The fact that people want to throw away everything just because it's not the latest and greatest is rather shameful and wasteful. This is why so many modern pieces of software suck, because modern programmers think you can just throw more RAM or CPU at it and solve the problem inherent in the code. That's the Rust way of thinking. Don't be like Rust devs, be like C devs. Keep what works.
This is not a good take, Bryan. The changes that the rust programmers have asked have all been with the intention to increase the quality of the C code base, and that just happens to also make the Rust code safer. By the way, the rust programmers are *also* Linux kernel programmers, they just do Rust in addition to C. They have not been jerks about it -- there have been discussions and arguments, but that is normal for anything development.
Maybe it's because they want it to be more versatile, in order to have a bigger pool of developers in the future. That's the only thing coming to mind.
Inappropriate or over use of Java has done a lot of damage to the software world. And it was fading fast when Android came along and gave it new life. Java has a role to play I suppose, but there are far too many one-trick-ponies that cram it in where it doesn't belong.(like machine control systems) All of the universities in my area are still using it as their base teaching language for CS (Extra stupid because it is single paradigm OO with GC and no direct low level machine access. So exactly the opposite of how to learn the fundamentals of computer science.). Some colleges have stand alone C++ and python courses, but they all insist on Java as a standard for transfer credits.
@@mytech6779 Completely agreed. The bare minimum for a CS course should be a language like C with some assembly sprinkled in. I would of course accept Pascal, Objective C, C++ and any other such language as a substitute for C, but C is the best choice, unless we're talking about inline assembly, then Pascal.
@@anon_y_mousse Usually the first quarter "intro to C++" is just the C part of it with a dusting of ++ sugar, they don't get to high level concepts of classes and such until later courses.
Rust simply doesn't allow the majority of vulnerability exploits and a very significant proportion of crashes due to its memory safe features that C isn't feasible to match. While C allows coders to more freely use resources like memory this rare advantage does not suit a stability and security first project like the kernal. A change in code in software packages requires structural changes. this is essentially never not the case and isn't very interesting frankly especially given the already dynamic nature of the kernal against the advantages of rust. The kernal project is in some ways very progressive and changing code structure to better fit rust before rust is ready is actually just looking ahead and demonstrates intelligent future planning. I hope this explains why even torvalds is in favor of a Rust direction. "If rust is beneficial it wouldn't be approached this way" why? also replace "is" with "was" or "were to be" (hypothetical/not past tense or future) and you might be closer to understanding. The rust maintainer leaving is genuinely interesting but you have connected it to too much and also people just do that in high stress projects like the kernal regardless of code language. also rust probably isn't going to be faster no one expects it to be overall and I notice a lot of false standard holding a lot in your video/thinking.
@@Bokto1 Total non response. Linux has already changed C language standard. The first C Unix did not use (at the time) standard C. C++ was not standardized until Linux was 8 years old. also "so many words" and you couldn't respond to any of them.
@@gr4tisfaction that is not a useful or novel bug prevention practice suggestion as everyone is already trying to that and top level programmers understand that rate of bug creation/interaction by any human or it seems for now even AI is not something that can even approach zero. its like someone saying just don't get into an accident in response to the impending adoption of seatbelts. You could discuss as to whether your particular area of driving should require them but just to say that in general is very dmb and just a non response.
What specifically does Rust do that C won’t? Is it capable of something C is not, or does it amount to that the Rust syntax is reputed to lend itself better to certain things?
Apparently it's hard to program C? Or they never learned good programming practices? Those whole debacle smacks of someone saying they don't want to wash their hands after taking a dump.
So it depends on the API and what the end user is trying to do. Two of the big abstractions being rewrite right now are heavily multi threaded. C is clearly not thread safe and can be a pain to get correct. Rust on the other had checks thread safety at compile time so its much easier to work with and be sure you have not introduced any bugs.
@@hahahano2796 Has nothing to do with difficulty. It's more that the history of programming has proven to us over and over again that even the best programmers in the world will make a variety of errors. Linux itself doesn't use "stock" C, they have all sorts of tooling, and wrappers around things to ensure a higher level of safety than what otherwise would be achievable if developers were left to their own devices. Rust is one of many attempts over the years to attempt to mitigate this human failability. There are plenty of ways of getting things wrong or writing insecure code in any language, including rust, but rust's thing is that it forces a higher level of specificity in what you write than other typed languages, enabling the compiler to check for correctness in a way that most other compilers cannot. Pretty much everything we have been up to in languages for decades one way or another tries to attack that core problem. Look at all the stuff C++ has added, look how libraries like boost, and the stl do things now compared to how it was back in the "C with classes" days. Typeless languages tried to attack it from a totally different angle by taking that control out of the hands of the developer and cleaning up the mess with a GC, etc. C is elegant and simple, I love C. And it definitely has it's place. But it's also like giving someone a race car with no brakes and then blaming the user that they didn't start to slow down 5 miles before a turn they didn't know about.
I think the reasonable argument is that Rust is designed for 'big systems', and it is probably true that a modern language with module system and better type system does make it easier to build understandable systems than C. However I'd also argue that trying to retrofit into an already complex C system is the wrong way to go - what exactly are these features that C is implementing that are so hard in Rust - at a guess it is flexible runtime properties that are 'easy' in C because you can just discard type information, whereas that is almost antithetical to Rust.
@20:36 Also what better way may be for language to be battle tested than became a part of kernel ? Whatever languge it be, there is no better mine field. Only risk for Linux kernel i see, is that if thing became more ideological/reliogiius some people will stop contributing.
Kinda concerning when you're (as in the people responsible for the change are) trying to change your preexisting work purely to satisfy something that inherently is unable to work as it stands and has no timeline to do so. It doesn't sound like meritocracy, it sounds more like obsession.
I like rust and its safety, but I think effort ought to be put into defining a standard, making an insanely stable version of the compiler, and then we can use it. Current rust can be seen as a sandbox, we can look at what works now, we standardise it, get rid of the accumulated crud and go forth with that.
The Ferrous Systems standard is already ISO 26262 and IEC 61508 compliant. While there are talks about putting a standard together the only other front end is still a good ways back(thus wont be used for kernel work for a while as it will have its own issues to solve). When they say stable they are talking about stable, beta and nightly not that the compiler is not stable. Right now they just need to get the ~32 features into stable and not stuck behind feature flags. The kernel can always be built with past stable releases of rust. It's just the some changes are behind feature flags.
@@justanothercomment416The zealotry is from the C developers who don’t want to have anything to do with it who are actively blocking and keeping abi implementations secret to hinder its introduction
@@justanothercomment416 truly. I just wanna enjoy my nice Rust code without all this drama. If we can't get into the kernel, that's fine! We can work on providing the features, then some day when we're ready we can try again. Just don't be assholes, it's not that hard...
Uuh so Im not a kernel or Rust dev but isnt this just a consequence of the release cycle? If rust support is spotty then no rust patches are going to make it in but that doesnt mean that all that work was done for nothing or that there arent useful changes currently waiting to get in. Wether Rust is actually safer than C can only be told when the compiler is stable but if it is a lot harder to hide unsafe code in rust than c that may really speed up the whole process. Also "Problems in the Kernel" could be Problems that are independent of the existence of Rust.
Why do you think anyone is trying to destroy linux? There is no motivation for anyone to do that. They are merely (with Linus's approval) trying to improve the kernel.
They actually have their own kernel (Redox). Interestingly, it looks like a majority of the more vocal Rust promoters don't care about it one bit. First level of analysis of that would tell us that they care more about trying to "fix" existing software than creating new software. You know, like some kind of "savior" complex. Second level may indeed suggest that the underlying intent is to destroy Linux or whatever else they "convert" to Rust. I don't know. That may or may not be intentional, but I sure would be extra wary of the major investors behind Rust. Just have a look and tell me if that sounds "trustworthy".
Because that is never gonna be productive. The biggest open source kernel still has hardly any users. Bsd is the runner up and is infinitely less significant. Nothing will be established for a kernel made solely for the programming language. Don't encourage unnecessary fragmentation. Improve what we already have instead
@@nullid1492 It would be when Rust can't even theoretically support ABI stability, a literal requirement for Unix and POSIX. (and not to mention the LGPL)
Microsoft gave up on backwards compatibility. They've been taken over by people wanting to do "modern" things and don't care what they break. Linux kernel at least cares about compatibility.
@@username7763quite the contrary, look at the win32-metadata project, where they're documenting the OS API's that they're not just documented books and ancient docs, that have become outdated over the years.
@7:03 I'm not most in too Rust or fur community, but even I know, that at this time stamp youre ranting on things, you have no idea about. if unstable for you and author of this article means nigthly, then you are mixing meaings. Nigthly means mainly that things are not accepted standard than they are working wrong. Also instead of just read that are 29 task of 81 closed, you say about "endless list".
@@nobiado484I don't think the linux kernel can build without non standard extensions. It feels odd to say that C can use unstable extensions but Rust can't. Rust is still in the RFC proposal phase you are basically saying the kernel can't have X feature because it's not 100% perfect.
@@nobiado484 Why? Rust still evolves and has robust and well thought practice of introducing new things without special troubles. And how? How Rust people may know about many things in millions lines kernel without trying to integrate in/with it? I can bet most of things on this list are for sane or safe integrate with some C quirks or some kernel developers "super smart" tricks.
@@dynfoxx It's not the issue of non standard extensions. You can get the GCC that ships with any distribution and compile your C kernel. You don't need extensions from a wish list, only partially available from a non stable bleading edge version of the compiler.
@@nobiado484 Integrating with the linux kernel is a unique project with some technical requirements not seen in any other software. It is therefore not unreasonable that some changes might be necessary to facilitate it.
@@eat.a.dick.google It's not a joke. They tried to implement a pure microkernel, after Apple tried, and came to realise it needs to be hybridised. Either way, the Hurd definitely needs the help.
From what I have seen it doesn't even look like a good language for the job. It has more the characteristics of an application language, or anything else self-contained and non-interfacing.
Agreed. Not sure why Linus likes it so much. As far as system languages is concerned, Zig is far better suited for kernel development as it is essentially a better C (it can even compile C directly), although it is even less stable than Rust.
@20:27 How do you know that ? I'm may bet that kernel is full of strange strucutres and incosistent API's wich are maybe battle tested, but are pain for any new person who must learn to walk around them, so doesn't matter if it Rust or C developers push to make things straight, it will benefit all.
making something more "beatiful" doesn't benefit anyone. those structures or whatever are like that probably for a reason, and done by smart people. if Rust cannot figure how to work with that, but asks that to be changed, it just begs for more issues and security vulnerabilities. You are basically asking for some battle tested things to be rewritten into something that won't be battle tested (and no rust, being a "memory safe" language does not guarantee that you will get anything like that in the end - memory safety is just one segment of good stable code).
@@marsovac it is not about beauty. In big, long projects reason why things are as they are is often long gone and new person trying to understand it may have a fresh look, worth of considering. I'm not asking for changes just because of Rust, every change should be carefully considered, by those vwry smart poeople. I don't think that anybody wanted rewrite at this time.
My guess is that the reason big tech wants Rust in the Linux Kernel is because the people running big tech (Government Intelligence Community) have their fingers in Rust and have it compromised enough that they can use it to compromise the Linux Kernel itself under the guise of, "More Secure".
Love it or hate it, we'd all be fascinated to lean how this open source compiler is compromised. Perhaps you could give a code sample that outputs some 'compromised' assembly? Or point to a line of the compiler that is 'compromised'? If this is not the case, then this is a conspiracy theory.
@@nullid1492 Proving assembly is compromised is non-trivial, proving that source code is compromised in a toolchain that cannot be source bootstrap is meaningless.
@@nullid1492 It may well be but compromising binaries via malicious hidden compiler code (i.e. code that no longer appears in the compiler source) is NOT a fantasy.
@@secretchefcollective444 this is technically correct. However why wouldn't someone compromise clang / gcc using the same technique (given that C++ is so much more popular)?
Please dont attack the people who enjoys anime just because theres an overlap between them and rust developers. Be a good journalist and stay professional
@@mytech6779 I believe the wording is accurate, I am no English native so I'm not going to contest it however. Feel free to suggest a more appropriate term if you like to. Whatever that works to help the creator improve their content
hey, I don't appreciate your tone here at 20:40 I for one, could not care less about rust for linux for now, I'll probably start caring when rust starts breaking the kernels I'm running
That was just a L take on his part, see several comments above yours, people with anime profile pics who wear cat ears are welcome in C userbase (notice that there is no such a thing as "C community") - sincerely, c enjoyers gang, degenerate front.
@@jaysonrees738 I'm laughing at the 🤡 who's parents named their kid Jason but with a Y in the middle of it because they really wanted him to be special LMAO KEK
@@RustIsWinning Your best defense against being called a zealot is a personal attack against the spelling of my name? I'm honestly a little disappointed how that's all you were able to come up with. I don't even feel like I need a proper retort.
@@jaysonrees738 Crying now JaYson Derulo? You laughed at my name and I laughed at yours. Stop being hypocritical. In fact that wasn't a defense because I could not care less. I did not even start my offense but you make it too easy. I know you will whine again lmao
Why the heck would I use some random nightly to build a production system? What the actual f.
You seem boring. Live a little, why dont you?
Amateur Rust user here, nightly (which I have used with embedded programming without issue) is most definitely not what should be used in Kernel development and I want to make that extremely clear. Nightly with rust is more stable than it sounds, Nightly is like the Fedora (which I use) of Linux; leading edge rather than bleeding edge. When Rust gets to the Debian stage, then and only then should it be used for Kernel level stuff. Until then it should stay out of it. I believe that parts of Nginx have been written in Rust so it is at least ready for driver and module stuff, just not core Kernel.
@@corey__wm Its still not ABI stable though and you can't work with it for dynamic linkage which makes it functionally useless for Unix infrastructure in general.
@@Spartan322 Interesting. Last time I asked about that very thing and made statements based upon this assumption people came out of the woodwork to attack and make baseless statements against me.
@@justanothercomment416 Yeah I've had that a lot too, criticism of it causes it, I've been call some pretty horrible things for my criticisms.
And what people don't realize is the most important aspect of C is the portability. What language lets you have a compiler on every platform in existence, even the tiniest ones. Are you going to get rust compilers onto all these 8 bit and 16 bit platforms? It is gigantic.
You aren't going to compile the full modern linux kernel to an 8 or 16 bit platform are you? Rust uses LLVM so can target the same platforms as clang.
Also you don't need to run the compiler on the target platform.
@@nullid1492 Yes you can and it would be stupid to kill these platforms
@@nullid1492 Its also not ABI stable so it doesn't actually have capability to support POSIX kernels and can't support a Unix kernel in the theoretical sense.
@@nullid1492 tell that to dmitry grinberg. he ported it to a 4004. a 4 bit cpu from 1971.
and why add complexity when it isn't needed? K.I.S.S. applies. adding rust to that mix just adds nonsense that isn't needed.
@@nullid1492 Yes, that's how real world development works. As an LLVM developer it is quite limited for architectures.
No language spec. No approval.
No spec. No language. Rust never existed, it's just a collective hallucination.
Imagine coding in a language that is not internationally standardized by at least two committees and have less than 3 compilers.
Literally bleeding edge unfit for production.
@@Bokto1 ThE cOmPiLeR iS tHe SpEc.
(But I digress, as a Common Lisp guy we've only got one spec and a handful of real time assembly compilers. But there IS a spec.) The worst thing you can do is tell people the current implementation is the spec. That's terrible and subject to change on a whim of whoever's falling from power at any given month. Don't trust a programming language that's not old enough to vote and doesn't have a spec. Age wise, Rust is still using a sippy cup and doesn't know what it wants to be when it grows up so it tries to be everything. That's exactly how C++ got into the mess that it's in now with complexity and undefined behavior. I estimate that Rust will soon blow past C++ in complexity, syntax, and shaky bridges between disjointed concepts. Perhaps it already has.
@@PixelOutlaw Undefined behavior is defined in spec though. It's relict of C that allows for C to be the most portable language, while remaining as efficient as possible.
The issue is Rust is supposed to be this deterministic way of programming, which it clearly is not.
I agree with this. With something as critical as rust you need "bureaucracy" like an ISO standard for the language
Rust developers are not stable enough for Linux kernel development.
Not the boomer humor again ♿️
@@RustIsWinning Cringe username
@@catto-from-heaven Cringe land animal!!
@@catto-from-heaven Cr1nge LandAnimal
Maybe the linux foundation can move some $ from AI and diversity to rust compiler development?
Rust **is** Diversity, blasphemer!
Rust 'is' diversity and AI
It's name says it all, it's Rust 😂
I thought importing foreign languages into a stable source is diversity and strength?
Stop being a bigot! 😆
Rust has an imperialism issue in addition to it's compiler issues.
its
Rust often feels like Soviet Imperialism too, no questioning the great leader type deal, constant purity tests, struggle sessions. The Rust Foundation trying to sue people in violation of the American Constitution pretty clearly demonstrates who its actually aligned with.
Very ironic considering the fact that they look like liberals
@@Spartan322 It gets difficult to distinguish all those subtle shades of red, they always seem to blend together...
@@Spartan322 What do you mean? As far as I've seen, the Rust Foundation would rather go completely against the US constitution.
Thanks Bryan. Wailing and gnashing of teeth will not change the facts.
1. Rust in Linux is not a matter of life and death and does not have to happen immediately. We have survived without it all this time. What we have now just works.
2. If the narcissistic Rust developers can't wait, then they can build their own kernel. It's not like it has never been done before. We know it is possible.
Nobody cares about another kernel, also still lacks ABI stability so it'll never get POSIX support and it can't support a Unix kernel. Its not even a potential thing, it is theoretically impossible for it as in accordance with Rust language developers and designers, Rust was not really developed with a consideration for the real world and its not the only systems programming language that carries its protections without a GC, its just the one with the most ravenous and easily offended fanbase.
There is system written in rust. Redox OS. They should move to that project instead on imposing their ludicrous ideas on Linux.
Using the word “…narcissistic…” sounds as if one is an a young American woman who got dumped by Chad and Tyrone because one thought they were a 10 when in reality one is a 2.
@@raidensama1511 Yes, same attitude. 😀
@@raidensama1511 we are in a tough position with that word because it is a very real thing, but the people who it actually applies to tend to pick it up and point it at everyone else. Reversals, distractions and word games are some of its core features
I never cease to be amazed at the lengths to which people will go for the illusion of safety.
They better get to it before it rusts completely
As a Rust lover, if it ain't ready, it ain't ready. I want good things, I don't want bad things. It's the entire reason I use Rust in the first place, and it's the reason we shouldn't be using Rust for the kernel yet. Why is the culture of FOSS people so toxic and absurd? We can be better, guys. We can just not be assholes, please.
Rust people, please. This is a young language, we have a lot of work ahead of us. C people, please, just document your code. It's not that hard y'all, if we were all nice maybe we wouldn't have a developer shortage.
Oh, screaming gods, you ask for *documentation* of existing code?
Yeah, I have seen that road graded before . . . .
But I have watched tremendous progress happeni, too; I remember when Ruby was new, and I remember when first "+" and then "++" were added to "C". Good luck takes good people, and you are expressing the right attitude to make it work!
@@jupitersky thank you for being sensible. The pushiness of the rust community is super off-putting. It's not just rust either. Python just "suspended" Tim Peters for crying out loud. And this business with Godot. We need to get the communism out of open source, stat. Let's get back to making software
@@livenotbylies Quite honestly, FOSS is often more dictators and oligarchies. Communism is what Wayland looks like... and uh, let's just say there's a _lot_ of arguing holding basic features back for many years. I believe it is a wider cultural issue with how people behave online, one which has been evolving and changing since the early days of the internet.
@@jupitersky I used the term communism somewhat loosely, but I don't think this is just behavior on the Internet getting worse. There is something afoot. I've been involved for 25 years. Western culture is infected with something right now. Something shifted about 2008 and has been picking up steam. I hope the fever breaks soon
@@livenotbylies Aye, I smell it too. It's definitely not just on the internet, but I believe that's where it originated. Something big is going to go down, but whatever it is hasn't quite taken shape yet. I feel like a paranoid schizophrenic saying this but... it's tangible, you know? Western culture its self is shifting as the older generations fall away and the new ones, born into and raised by technology are forced to reconcile with reality.
File this under "No sh1t, Sherlock."
Rusties constantly try to disingenuously compare their nightly build features to 35 year old unstandardized versions of C++, while also completely ignoring the amount of validation work that goes into the latest ISO standards and major implementations of it. Rust doesn't even have a comprehensive published standard.
Do we need a standard for the kernel?
@@RustIsWinning There is, it's called POSIX. Although a better standard would help improve porting of commercial software and hardware drivers.
C++ is a really bad language and needs a replacement. Really really bad. Modern languages like D are slowly becoming wrappers for it. But as more developers get fed up with c++, more people will switch to better alternatives
Exactly!
@@ollicron7397 Cool story bro, in the mean time the work is getting done with C++.
Requiring nightly builds of a compiler is a no-go for industries that make mission-critical and safety-critical software and require well-tested and certified compilers.
In some of those areas, even C++ has trouble to make an incursion into, much to my dismay.
The beauty of C is that it hasn't changed in ages, and the ISO C committee is incredibly conservative in making changes to the standard.
Rust will never set foot on those industries as long as this culture remains.
True. C and Ada rules in this scene.
The Linux kernel doesn't even use the most recent gcc version.
Quick correction it is not using nightly builds of the compiler it is using stable releases but nightly features.
Rust has a certified compiler.
The beauty of C is that the kernel is not using normal C and you need an LLVM compiler from 2022 to build the kernel.
Yet adding another language needs a compiler in stable today when it took the next largest C compiler ~10 years to be able to compile the kernel.
They are setting things up to fall into stable builds and it looks like they on track to beat LLVMs time which feels crazy.
Good news. I was baffled by the idea of mixing a foreign language into the kernel. C and ASM. That's it. But rust fappers are on the wagon to make us all "happier".
PS. To Miguel Ojeda: My flexibility ends with erected middle finger.
Another useless bait. Do better.
@16:14 It's the goal because it's presence in there is for nefarious reasons. Otherwise the push wouldn't feel so bizarre.
Capturing Linux didn't work the usual corporate ways, so now MS et. al. build support for and code a trojan horse component.
Gee, didn't the xz project try something similar?
@@Mavendow And almost succeeded if not for a rogue MS employee. Weird, no?
It's right in the name and the logo, they put right in your face. Rust. That's iron oxide, produced by the oxidation of iron. They're rusting away the existing support structure. The logo is a crab. That's the sign of cancer. Rust spreads like a cancer. Crabs, ie crustaceans, arachnids, and so on, don't use iron for oxygen transport. They're blue blooded, ie they use a copper compound, hemocyanin, not hemoglobin. You can also count the number of teeth they put on the R gear, and the five holes surrounding. R either refers to 18 or 9, so look at the 18th or 9th pentagonal number. Contrast it to the number of teeth on the gear, which is 32 to my recollection.
It's all right there. A copper based blue blooded creature, the sign of cancer, is rusting away the existing infrastructure and replacing it.
rust never sleeps...
They did use a lot of weird symbolism around the language
@@etherweb6796 Yeah, they did. All of that, + the aggressive cult-like and quasi-militant approach to engulfing other projects, with the odd corporate backing, all told me something was up. It's unfolding a lot more clearly now. The other thng is the "Crate" concept and the build / package management tool "cargo". A reference to a cargo cult.
Lot of little things that may at first appear tongue in cheek, ironic, or self deprecating. Even humorous, a parody. When that's the kind of doublethink environment they're going for, and they actually mean what they say.
@@Acetyl53It's like listening to a freemason smirking while claiming "it's not a religion". Spoiler alert: It's a religion. And it cannot withstand sunlight.
I don't go in for all the numerology stuff, but I would believe that the rust cult believes it.
It's about the money. They take money from Microsoft, Google, etc. to push rust adoption. Microsoft hopes that rust will sabotage the kernel development, the linux guys think that they can take money and sabotage the sabotage.
I'm the person who posted that to Reddit, which is where I'm guessing you found it bc you uploaded this the next day. I don't agree with you ideologically or philosophically, and in fact I don't have a problem with Rust in the kernel per se. The reason I posted that is because I felt like some disclosure was in order regarding the big tech forces pushing Rust in the kernel bc people say things like, well Linus wants it in there. But to me it was very clear there were powerful forces working behind the scenes that were pushing for it, and my suspicions were confirmed by what Ojeda said. And as someone who values libre software, and given the history of those specific big tech corporations violating the GPL and other treatment towards libre software, it did certainly pique my interest and I felt like a public service announcement was necessary.
Truth is an ideology now?
> the big tech forces pushing Rust in the kernel
That's exactly why anyone and everyone should be avoiding it.
I haven't seen anything good in standards pushed by big tech in 'recent' years. By recent I mean all I remember.
While it would be insane to rewrite project X in language Y that it wasn't already written in, a completely new project using language Y might make some sense. Towards that end, it would be really cool if someone implemented the entire feature set of QB4.5 for modern PC's, but upgraded of course, and then wrote a completely from scratch kernel as a project. I know some people would point towards FreeBASIC, but that wouldn't have the same cool factor as using QuickBASIC.
_>not stable enough_
So are they describing Rust or the Rust developers?
Both :)
Yes.
Says the lonely guy with cats LOL 😂
@@RustIsWinning Says the guy with cat-ears. LOL 😹
@@Ubu987 Not cat ears but programming socks. What's wrong with wearing cat ears anyway?
Here I was thinking they had crossed their T's and dotted their I's for the amount of noise they make about putting this thing into a production operating system kernel. Good god,
Oh we dotted our i's and crossed our t's... _by listing the stuff we can't do yet lmao_
If only programmers would stop being so fanatical about stuff, then we might be able to get stuff done.
Wild stuff, truly wild stuff.
Oh god. the weirdos that post on every channel that so much as mentions Rust will now brigade this comments section. The worst are the ones that have Rust in their username. shudder.
Rust is probably the most toxic developmental community I've ever seen, I don't think I've ever experienced a worse set of human beings who all associate with each other personally in my life.
@@Spartan322 I fully agree. It is really ridiculous how bad it is.
@@Spartan322 The wayland people are very close too.
@@Spartan322YourGrandmama is toxic 🤣
I'm starting to think that Rust is a three letter project for dubious reasons.
Same, I've long suspected its an attempt to undermine after failed attempts for the powers that should not be failed to imperialize the ISO body.
Im starting to see C slowly go extinct.
@@skuwamy Not based in any reality.
@@skuwamy lol. Not on planet Earth.
It does seem overly political for a programming language. It also reinforces doing things a specific way to make things "safe"
Rust is great, and I agree that eventually it would be great to have a kernel built from scratch in rust.
But I wouldn't push into linux unnecessarily. If the C devs want to use parts of Rust voluntarily, I would assume even stable is usable for some things, but there is no reason to bend over backwards to push it in.
There are really shady smelly influences when I see rust being pushed that un-naturally
The C dev (Linus) wants Rust in linux voluntarily
@@ythanzhang But the Rust people want to push their luck and do so before it is even stable and ready.
thats ok rust enthusiasts ; maybe another 50 years rust can have the similar quality level of support, tools and reference material that c had 30 years ago
It took less that ten year to for c to become international standard, rust doesn't have a formal grammar yet, let alone becoming standard
@@arkeynserhayn8370oh man, I pointed these very facts out in a similar TH-cam video and the level of butthurt it raised was unreal. even hint that it's an immature language and you can snell the unwashed nerds dander ruffling up through the responses
@@arkeynserhayn8370 what even is formal gammer here? Rust is pretty strict about its syntax already
@@RenderingUser
Formal specification in which syntax is defined. It's not about how a language is strict, it is about having a formally-defined parsing-consistent syntax.
Fun fact: JavaScript while being dynamically typed is syntatically consistent. TypeScript while being more stric type-wise has a parse-inconsistent syntax.
@@arkeynserhayn8370 yea rust does have that, no? if anything its better since nothing is hidden.
I really had high hopes for rust, then lost it but thought "okay, for a kernel its probably fine" - then lost it...
I feel rust is NOT "the language" - more like an evolution step that moved waves on the water so real "the language" can come - actully started working on one...
Lang name and formation ideas?
@@arkeynserhayn8370 It's called BASED. It has no borrow checker but a system based on semantics and syntax which is much simpler yet handles 90% of cases (and its clear which case it does not). No GC. No OOP. Also has pretty heavy metaprogramming because the compiler is fully scriptable (but its not like Zig comptime so its an other language which is somewhere between FORTH and C). There is also a very new system for generative programming that I never have seen anywhere before and makes writing stuff much easier in my opinion.
Very closed for now. Will be open source if I find it is stable enough. In this I follow the "Cathedral" and not the "Bazaar" style. I think for a language the Cathedral style and having conceptual integrity is really needed.
@@u9vata
Once you fully docmented all the formation ideas of your lang, learn about ATS, a ML-like systems programming language with strong support for generative programming; it implements type-level proofs and linearity checking for correctness.
I said dont look at it because i dont want repetition of ideas, i want people who design PLs to come with raw and new ideas, and implement them in POC languages with weak developer dynamics.
If you feel like it, replay to me once it went public.
Honestly I find C3 the better language for this anyway.
@@arkeynserhayn8370Fstar is more widely used and higher level than ATS, and involves less manual proving.
It's not just the stable rust release. Its the stock distro must support it. If i can't download the kernel and build it without jumping through hoops to get packages from outside of my distro, the process is broken. This isn't even a "kernel developer" problem, it's a package maintainer problem, a "i like custom kernel builds" problem, etc.
Compiling an OS in a language without a stable ABI is insane.
Let’s use Haskell to compile Rust to C!!
This is the way.
Thanks for mentioning Forth!
Yes? That's kinda the point of a "stable" branch; to be outdated and not have new features. Gotta be honest this feels a bit like a manufactured story. "New endeavour requires tooling not already developed!" isn't exactly breaking news, that's kinda how things being 'new' works. If I buy a 5090 and it doesn't work well because I'm using Debian stable LTS, that doesn't mean either debian is bad distro or that the 5090 is a bad card, it means I'm being an idiot and trying to use brand new hardware with a "stable" (see : slow) OS.
In other news, use of hammers called into question after recent study revealed that using them to break lightbulbs will lead to some lightbulbs no longer functioning properly. More at 7.
This weird desire people have to act like Rust devs are somehow "forcing" Rust into the kernel just because it's new and shiny has always fascinated me. Well, maybe not "fascinated" but its certainly a strange case of confirmation bias. Linus hinself still gets the final say on what is/isn't allowed in the kernel, and he is about as antithetical to "ooh shiny" as I can imagine a (vaguely rational) person getting. If any single person on the planet alive today was most qualified to say what is/isn't suitable for kernel level development, it'd be the guy who literally invented the kernel that the entire world runs on, and it's in there under his whims, so acting like its somehow being "forced in" requires a geuinely intriguing level of either confirmation bias and/or straight up delusion.
I think the issue is that not only do you have to use the unstable nightly build, but that even that build is not capable of doing the work needed. Currently the nightly build is only capable of doing certain parts of the kernel. So, while you may want to do this, and it may be the correct thing to do. Pushing it now, when it is not capable of doing the job, and the only way you can even get it to do small parts of the job is to use nightly builds is dumb. Develop the language until it is at least capable of developing for the Kernel before mandating it.
As someone with an anime profile picture, please continue making fun of furries, mastodon users, and Rust software developers. We will not claim them as one of our own. They're punishable for stolen valor.
Fellow degenerate of high culture 🍷🗿
And btw, he seems to lack information about inner dynamics of otaku individuals, for one, otaku people and furries are mortal enemies.
And remember mastodon isn't the fediverse. Fedi has some of the most based places on the Internet.
@@SJ-co6nk X to doubt
Your right, you guys are even worse.
I might crucified for this, but: If I were to add a new language to the linux kernel, would be C++. Makes more sense and it has proven to be solid over the years.
Keep dreaming LOL
To be fair, Rust is stable enough to write a kernel from scratch. It's not stable enough to work with extensively alongside C. If you wanted to implement Linux in pure Rust you absolutely could, the problem lies in integrating with the existing codebase
Then why don't those people go work on the Redox project? It's a linux compatible kernel fully in Rust. Writing a kernel from scratch directly in Rust should be better for them.
@@Vitis-n2vTell that to Linus.
hahaha@@phantombeing3015
And while whole world is depending on existing code, I can understand that this doesn't happen fast.
As far as I know, Rust code will run something like 1,04x slower than C, and language itself is not as stable while last version of C was 2011, I don't think Rust is the right tool for the job.
I believe that instead of using Rust, formally verified C is better route or even write domain specific language for the job.
@@gruntaxeman3740When Linux started nothing was stable. Linux still survived. Rust is quite mature. Interop with C might have room for improvement. Using it will show where it needs more work.
In software there are 2 states. Old, stable and unflexibel vs new, less stable and innovative.
Your stance will just lead to death. Rust can rejuvenate Linux.
Quick Basic was a great language for beginners, back in the days of DOS. It was much easier than learning programming with a language like Fortran77.
I cut my teeth on basic good stuff
I'll stick to my 6502 machine language.
I started on GWBasic -> Quick Basic -> Quick Pascal -> Quick C (The first 3 were taught in my highschool) and honestly once I got to C, I never understood why anyone would waste their time with basic or pascal, they seemed utterly pointless. Generally the argument was that it makes teaching the basics of programming easier, but the kind of things you program while learning are simple regardless. If I were going to teach a beginner programming class I feel like you're better off starting with basic examples in assembler and work up from there. Learn the truth, not worthless abstractions.
@@entelin I hate to tell you but many a Quick Basic programmer made bank writing shareware apps back in the DOS days. I saw one grad student write a wind tunnel control program with Quick Basic that probably would have taken him months longer in C.
Also, many programmers who learned in Quick Basic graduated into the MS Visual Basic system and had careers in software development. So, worthless? Not at all.
It never mattered if Rust was ready or not, the only thing that mattered to the people pushing for its inclusion in the kernel 2 years ago was to full fill the religion goals, just like some other projects take it to the point where they weaponize the dependencies and take over a project.
Mark my words, if you give them a hand, they will take your whole project and eventually kick you out for not adhering to their religion or their code of conduct.
For sure. One obvious point is indeed that if there are enough Rust devs in the Linux project, their "code of conduct" will prevail and Linus absolutely doesn't fit it. So he would get kicked out one way or another, and I'm sure that's their goal.
I miss LJ. It was as the one remaining publication that I liked having a print copy of. It didn’t seem quite the same when it went digital.
Frankly these rustolians are blinded by their own hubris.
What on earth does any of this mean
@@RustIsWinning average rustacean level of reading comprehension
You need to be able to compile the most recent Linux kernel with the Rust packages that are in the standard repository of the oldest still supported Ubuntu system. E.g. Ubuntu 20.04 (Long Term Support Release) currently includes rust-1.80.
If the first Rust version capable of being used for the Linux kernel is the one that ships with Ubuntu 24.04, then Rust can be used for Linux development beginning in the year 2027, when Ubuntu 22.04 goes out of LTS.
No such Rust version in 24.04… 26.04 at the earliest. And that's still doubtful at this point.
Common practice is to be compatible with all current and previous production OS.
Currently:
-Debian 11 and 12
-Red Hat Enterprise 8 and 9
-Suse Enterprise 12 and 15
-Ubuntu 22.04 and 24.04
etc.
Suse 12 is however in extended support so may be that doesn't matter so much.
Does the federal government has a part in al of this bco their "safe" (and effective😏) software considerations?
Rust is coming close to its 10th birthday here, and it's "too soon to ask the Rust community for a completely stable compiler to build kernel code with". I struggle to see how Rust devs expect anyone to take their language seriously if building a stable compiler within 10 years is too much to ask of them.
The RFL project did not start 10 years ago. Check your facts boomer.
@@RustIsWinning if you really want to count pre-1.0 that only makes you look worse
@@exotericidymnic3530 Clueless deluxe lol. I said RFL. The Linux kernel requires new features that the compiler did not have. Those features were developed 2-3 years ago. The compiler is stable. Yall misinformed on everything lmao
@@RustIsWinning I'm very curious whether you think RFL means they ported Rust so that it works on Linux systems.
@@exotericidymnic3530 Holee the amount of ignorance lmao. RFL means bindings for a 2nd language. There is no port. There are specific features that the kernel needs that the Rust compiler did not have. How hard is that to understand?
I think zig would be a better fit for getting a new language into the kernel along C.
Yes, zig is not 1.0 yet, but if they start focusing now on getting zig into the kernel, by the time it will reach 1.0 it will be stable for linux too.
And that might even be before rust gets all that list done.
Frankly, I think that when rust will get that list done, irrelevant of the time-line, the language will be so complex that no-one will want to use it.
Womp womp my zigga your lang did not make it hahaha 😂
So what you're saying is we should switch from Rust to Pascal programming as the alternate language for the Linux kernel? ;-)
This is the last drop in the glass Rust on Linux was lost since the beginning😂
Programmers hate languages that make them think about how they layout their code and make arbitrary mutation more difficult (for safety)
No, it's just other programmers who hate (or simply are not qualified enough) to think about what they do in a program, so they need a compiler to rely on in every way possible.
Not every design decision requires absolute stringency. It's the equivalent of always checking bounds or always checking for a null pointer in internal code where the checks had already happened upon entrance to the library and no longer need the checks. Unfortunately, most compilers aren't capable of detecting when it isn't needed in heavily nested code and still require a programmer to know what they're doing and think about it properly and thus to give hints to the compiler.
I think we should keep religion out of the kernel
Should keep it out from everything else
As a Christian, I agree.
Your beliefs are a religion. Our beliefs are simply a rational worldview. So off to gulag with you.
Dunno man, TempleOS have better UI than gnome, so maybe they are onto something...
@@Bokto1 well, it's technically not part of the kernel
Rusties waiting for the Year of the Wayland RedoxOS Desktop be like
C devs waiting for the year of C (it already passed 30 years ago)
@@RomanAvdeevX And every year's been the year of C since. Nothing dethrones it. You have C and you have C++ and everything else wishes it could dominate
@@RomanAvdeevX
Nearly 70 of all the software in debian repo is written in C, SLOC-wise. C is the underpinning of the computing as we know it.
@11:55 , when you start cutting corners see what happened with Boeing
We need to bring Dennis Ritchie back to slap the Rust out of those wannabe devs
I swear they are like webdevs by daylight who want to do something systems development/electrical engineering but they dont want to touch microcontrollers.
As a Rust user myself who uses Linux, I have to agree. If meritocracy says that it can be apart of the kernel, then and only then will I be okay with it being there. It is easier syntactically to read, however, if it isn't ready then keep it out. Innovation can be a cruel mistress, we shall see how Rust fairs in a decade or so within the kernel.
@@corey__wm
Rust should stay out of a monolithic c-written kernel.
People who want to do systems development in rust specifically, should work on their on kernel with a toolchain that suits their preferred language, not shoehorn it into existing projects.
Rust is fairly okay for business logic applications tho, nothing groundbreaking, but not bad either. It has it's tradeoffs.
Dennis Ritchie would lose in a 1v1 fight against a crab. Let that man rest in peace.
Welcome to the era of enshittification.
Rust seems to be a magnet for software holy wars. If the language is presently too half-baked to implement what is needed, it probably shouldn't be a priority unless they're putting resources into implementing the language.
It could be that it's necessary because Rust wants to get into an area that was covered almost 100% by C and many C developers are comfortable with that and resist change. Breaking up monopoly doesn't happen by itself.
Finally I still have a few Linux journals on my bookshelf as I like to reread topics now and then :-)
Pretty sure there was some kind of national security announcement a while back advising everyone to write code in Rust. There’s a lot of industry push.
That whitepaper advised people to write code in memory-safe languages, not just Rust. For all that matters, we could start writing code in a more mature and stable language like Ada. But people default to Rust because they all want to jump on the bandwagon of the latest, greatest hype.
@@TawaraboshiGenba That paper seemed a bit political and unnecessary, rather than a truely useful technical advisory for experts. Like the agency employee that wrote it is probably a rust fanatic just looking to undermine the alternatives. Not that it promoted Rust specifically (that would be too obvious), but its focus on an outdated misrepresentation of C++ (Rust is really trying to be C++, not C), and in that that whoever wrote it seems to lack the basic knowledge of languages standards, compilers, validation, and computer engineering to know the structural difference in execution between Python, Fortran, or Java. Like yeah I'' just go write this driver in Javascript and glue it in with some C#…
@@mytech6779 That's most Rust devs really. They lack the basic understanding of pretty much everything.
21:23 Ada mentioned! Nice. That's one is the good language for kernel development, and is natively supported by GCC!
Tell me one good thing about Ada please. What's so good about it?
@@RustIsWinning Are you a troll or do you sincerely want to know what's good about Ada? Ada has much better safety guarantees than Rust and it is battle tested language which is used in avionics for example, where high reliability is very important. Is it enough of explanation? If you want to learn more just google "Ada SPARK" or "Ada Ravenscar profile".
@@RustIsWinning Do you sincerely want to know? Ada has very strict type system and provides better safety and reliability guarantees than Rust. Is it enough of an answer?
@@AleksyGrabovskiYes that's why I said please. So Ada requires spark? Is that an extension? Also how come that it isn't popular? Could it be because it doesn't look like C?
@@RustIsWinning SPARK is a subset of Ada. If you want even more safety guarantees you can use, so called "Ravenscar Profile" it will make it impossible to compile a multithreaded program with a deadlock, but it is difficult to program, because of different restrictions. So basically you select different level of guarantees depending on a problem. For example multimedia application doesn't need to be very robust and you can program it in full Ada, but if you want to write a microcontroller for a drone then you might want to have the strictest possible subset. And why isn't it popular? I don't know. Popularity doesn't always reflect quality. I think Ada doesn't have good marketing.
I think you'd have to take it point by point... If someone said, hey rust is having problems because you have a double free here and the maintainer replies with "I hate rust and that code has been stable for decades." It's not really an issue with rust that the current C code doesn't work with it.
If I had to choose between someone using floppy discs and someone using the next thing after USB pen drives to believe in deciding how things should operate... the guy and his floppy disks can kick rocks.
But Rust isn't able to be ABI stable so it wouldn't work anyway.
@@Spartan322 gcc and clang aren't ABI stable.
@@cheako91155 They can and do produce ABI stable binaries (something Rust can't do) and they can produce compatible ABI stability on the same architecture and platforms, C is capable to do this where as Rust cannot. All usable C standard libraries are legacy stable, Rust also does not have this, it is incapable of doing this.
@@Spartan322 no, the kernel checks modules b4 they are loaded and if the compiler versions don't match the load fails... not only are there compatibility problems, compatibility is expressly forbidden.
It should be noted that if Linus thinks that parts of the kernel need to be fixed, there's a decent chance that maybe it was a bad design in the first place that only survives because it already exists.
I remember having problems with a buggy C++ compiler once. So I switched to a different compiler vendor. All Linux has to do is choose from the many different rust compilers that meet the Rust language standard. Hmm, I guess those don't exist. Doesn't seem like a great language to adopt for a long-term project.
If two stable and mature compilers existed across most architectures like is available for C or C++ a lot of the objections would go away. But there are still issues beyond that.
Well they do, but they are not stable.
@@shadowangel-ou6bg Just minus the arch support, stable or more than one implementation.
@@eat.a.dick.google Or any language standard for said mythical implementations to follow.
Not a dev, just a plebeian normie here. I was genuinely excited to hear about rust. But in the end I just want an OS with a working kernel. I don't care what lang, just a working kernel.
So, Rust is actual programming Rust
Time does not guarantee a piece of code is "battle tested". Tests guarantee that a piece of code is tested. Just take a look at your other video related to the CUPS CVE with a 9.9 score. Even the unstable rust compiler has lots of tests to make sure it does what it says on the tin. You're contradicting yourself, why is CUPS not "battle tested"?
CUPS is battle tested, and that 20 years of testing revealed a weakness which can now be fixed.
The Linux project allowing another language besides C is a big deal. The only reason they would allow the possibility of adoption of another language (let alone far from ready with working well with integration with the existing kernel) would mean it would have to have such a compelling set of features that improves the quality of the kernel. Rust does a great job of modeling systems-level code with less and aiming to be zero undefined behavior and better tool-able to build safe systems. Don't get me wrong, C is a great low-level language and can currently do things that Rust cannot, but it has a lot of problems with being early to market.
I do hate all the drama with Rust and both sides need more empthany for each other. C and Rust developers are very different. C developers aren't being helpful commenting about how Rust developers dress and their personal lives and Rust developers should be more tolerant of those who made a world class operating system, these guys built the best open source project without tooling telling them it's safe or unsafe to do so, that's just bad ass, and they have a lot to learn about those that shipped something so grand and so heavily used it blows my mind.
That said, this video feels like a lot of FUD. No idea if this will work out, but Linux was created because someone said how hard could it be. How about you let others try, learn, and explore and stop talking about how pathetic their first attempt is. We were all there at one point in our lives where we have big ambitions and bit more than we could chew. I think a more productive path would be to set reasonable boundaries and otherwise let the experiment continue, with the goal of learning with a stretch goal of this might actually work.
This ^^^^, Another thing to keep in mind is the Linux kernel required and in some cases built custom extensions in GCC to actually compile and function properly. It's natural and expected that a big new use case for the language will expose the need for new feature and where existing features need cleaned up or fixed. And it's not the sort of integration that will get easier as time goes on. The projects need to hold hands and work closely together to avoid devolving into a total mess.
Integrating any new language into the kernel was bound to be hard, but Rust offers significant reliability and safety features, plays well with C and is reasonably stable. Zig isn't anywhere close to as stable, C++/D offers few advantages for the headache, ada has runtime assumptions that don't play well with the kernel, haskell is inscrutable and has garbage collection.
The sense I got about extensions to the gcc compiler was it was more focused on getting it to work where Rust seems to build out features properly and general purpose and that takes time to stabilize. I see great potential in Rust but people need to learn to get along on both sides.
*laughing in C*
It's so trendy to hate it, but it still just works! And without any of the ridiculous drama...
@@PassifloraCerulea and compilers are available pretty much everywhere without issue unlike Rust.
There are good reasons to hate C, but no reason to replace it. C's so great because it's the standard. Rust will never be because it's so complex and doesn't fulfill any of the roles in the ecosystem that C really does.
It is so over for C. First the kernel then the devs hahaha
@@RustIsWinning Mental health issues much.
Back to the drawing board until it's done! Languages that are not embarrassing (that's you, Python) are hard. Pleasant languages are harder.
Does Rust have some wins under its belt yet?
As a Rust user I agree. I use Linux infinitely more than I do rust. If my Kernel breaks, then what good is Rust when I can't use it.
Most of the cool new tools today are built in rust. I'll take that as a win for rust I guess.
@@RenderingUser None of them are ABI stable, so none of them are non-Rust usable libraries, they're all all end user programs or Rust-supporting libraries, no Rust library exists that can be used as a binding for other languages while maintaining the stability of C, that makes it useless for Unix infrastructure, and the Rust language devs refuse to cooperate on this, its so far considered theoritically impossible to accomplish this.
@@Spartan322 wdym non-rust usable libraries?
@@RenderingUser You can't rely on Rust in a library fashion like you can with C for anything that isn't compiled by a Rust compiler, the lack of a stable ABI means that it does not make any promise for dynamic linkage.
Show me on the teddy bear where Rust touched you
This would be accurate to reality if you said "every other Rust dev"
For my last 2 employers, I'm programmed in Rust and Go. Maybe I'll go back to BCPL.
You're right about PERL... though still useful... but it's like slitting your wrists while doing sth. productive.
Rust can improve the kernel a lot. But it has that one tiny hurdle, that it has to overcome. ("tiny")
And while Torvalds has some controversial opinions, he's right on this one.
Cat-ears or not.
Rust is great for kernel development, but it has to have a stable toolchain.
I am a Rust user, I would say that the earliest Kernel stable toolchain is unlikely to be in this decade; as much as I would like it to be within.
"Rust can improve the kernel a lot." xD Adding new languages to a code base is like taking immigrants in. 99% of countries on this planet were founded by one ethnic group of people. I don't get the idea of breaking a code with language THEY/THEM DIVERSITY.
@@hadeseye2297 while I get where you are coming from and I agree mostly with it but not absolutely. I cannot take the NPC profile picture seriously 😂. Anyway, have a good rest of the week.
@@CommanderRiker0 "BUT RUST FORCES MEMORY SAFETY!" Unless you use it in a kernel, where in many parts you have to dick around on the bare metal (which many folks don't understand: the C in an OS kernel isn't the C you write for an app) and that very often requires being "unsafe".
@@hadeseye2297The bait is really bad. You can do better :)
Compilers are to assembly what Copilot is to JavaScript
Rust must land in the kernel because that's credibility and visibility that Rust needs to spread. As they say and you quoted, it's a Flagship (capital F) project. Just like git won at least in large part because of being used for the Linux Kernel, so they hope it will work for Rust.
Also, looking at this I remember discussions around DRM/DRI back in the early 2000s, and how much difficulty the DRI devs had with Linus (reasonable reasons, I need to add) about a new API being accepted. Or the barrier for new modules new drivers… Rust had it *WAY* easier. Thanks, I'd say, to pressure from Google, Microsoft etc.
And another thing: Rust brings memory safety, right? But that's largely it, to my understanding. Now, I'm not discounting the problem of buffer over/underflows and related problems. But that's not the only source of vulnerabilities. Just for example, how would Rust have helped (tangentially, I admit) with the CUPS exploit that just came out? Answer: it wouldn't.
Another one: Apple GPU kernel driver is being written in Rust. And the pressure of getting that, when finished, into the kernel will be *very* high. EDIT: Or maybe not. I forgot, in a moment of weakness, how few people run Linux on Mac hardware.
There are two type of languages the one everybody struggles about and the one that nobody uses . Looks like Rust is becoming the new C++
I remember that time I wanted a stable, simple OS at work, so I installed Debian. Hadn't run Debian since the day debootstrap output stopped fitting on my USB drive. Running update-initramfs on a virgin installation would break the OS. Kernel panics preventing boot up. Ended up installing DragonflyBSD instead. Have considered Debian to be too unstable for production use since circa 2014. And too fat for minimal systems since circa 2010. Ironically, the Kali installations are at least that old, so we consider Kali to be stable enough for some production use (but not Debian)
Oh jeez I miss quick basic. I used to write sorting algorithm visualizations in it. Nowadays there are dedicated yt channels for that
Sounds like you are messed up something. Debian netinstall image takes only 180Mb. It is very well suitable for production use.
@@gruntaxeman3740 my USB is 64 MB. It's my first USB. I still use it as a boot medium in my cluster. Just can't fit Debian anymore. Since the system ramboots and runs on very old hardware, this was a deal breaker. I remember the day that happened because that was the day the Finux stopped running Debian.
As far as messing something up... Do a normal installation with default options, sudo apt update, sudo reboot, then kernel panic. By my standards, that's not suitable for production use. Maybe they fixed the bug since 2014. I wouldn't know. I switched to distros that don't have that problem.
In other news, one of my Kali laptops finally expired this year. It was installed in 2007. I use that as a litmus test for stability: if your distro can't do that, then it's objectively less stable than Kali Linux -- or backtrack, I suppose
@@innovationsanonymous8841
Cheapest USB sticks what we bought to give free for our customers 12 years ago were 2048Mb. They were like pencils with company logo or business card.
And when we are talking production use, something like used in hospital or logistics. We are not talking some garbage found from landfill. Looks like you haven't seen real production system in your life. Cheapest virtual machine today that is available has 1Gb RAM and 10Gb storage.
Your issues are likely related to computer found from landfill, not OS.
@@innovationsanonymous8841
Chepest USB 12 years ago were 2048Mb.
Very old hardware !== production.
@@gruntaxeman3740 I think he's got a point here. If it still works, it's still valid. The fact that people want to throw away everything just because it's not the latest and greatest is rather shameful and wasteful. This is why so many modern pieces of software suck, because modern programmers think you can just throw more RAM or CPU at it and solve the problem inherent in the code. That's the Rust way of thinking. Don't be like Rust devs, be like C devs. Keep what works.
bryan still thinking linux doesn't have as much furries as rust is still odd to me
The worst part of Linus's statement is "for some time yet". It should've been "ever".
This is not a good take, Bryan. The changes that the rust programmers have asked have all been with the intention to increase the quality of the C code base, and that just happens to also make the Rust code safer. By the way, the rust programmers are *also* Linux kernel programmers, they just do Rust in addition to C. They have not been jerks about it -- there have been discussions and arguments, but that is normal for anything development.
Maybe it's because they want it to be more versatile, in order to have a bigger pool of developers in the future. That's the only thing coming to mind.
People were saying the same things about Java that they say about Rust when I was in school.
It’s just a marketing strategy. Nothing more.
Inappropriate or over use of Java has done a lot of damage to the software world. And it was fading fast when Android came along and gave it new life.
Java has a role to play I suppose, but there are far too many one-trick-ponies that cram it in where it doesn't belong.(like machine control systems)
All of the universities in my area are still using it as their base teaching language for CS (Extra stupid because it is single paradigm OO with GC and no direct low level machine access. So exactly the opposite of how to learn the fundamentals of computer science.). Some colleges have stand alone C++ and python courses, but they all insist on Java as a standard for transfer credits.
Don't disrespect Java, it actually made software more secure
@@mytech6779 Completely agreed. The bare minimum for a CS course should be a language like C with some assembly sprinkled in. I would of course accept Pascal, Objective C, C++ and any other such language as a substitute for C, but C is the best choice, unless we're talking about inline assembly, then Pascal.
@@anon_y_mousse Usually the first quarter "intro to C++" is just the C part of it with a dusting of ++ sugar, they don't get to high level concepts of classes and such until later courses.
yuck, I always do my best to avoid installing JVM on my system. What utter garbage, who needs _more_ bloat with no upside
Rust simply doesn't allow the majority of vulnerability exploits and a very significant proportion of crashes due to its memory safe features that C isn't feasible to match. While C allows coders to more freely use resources like memory this rare advantage does not suit a stability and security first project like the kernal. A change in code in software packages requires structural changes. this is essentially never not the case and isn't very interesting frankly especially given the already dynamic nature of the kernal against the advantages of rust. The kernal project is in some ways very progressive and changing code structure to better fit rust before rust is ready is actually just looking ahead and demonstrates intelligent future planning. I hope this explains why even torvalds is in favor of a Rust direction. "If rust is beneficial it wouldn't be approached this way" why? also replace "is" with "was" or "were to be" (hypothetical/not past tense or future) and you might be closer to understanding.
The rust maintainer leaving is genuinely interesting but you have connected it to too much and also people just do that in high stress projects like the kernal regardless of code language. also rust probably isn't going to be faster no one expects it to be overall and I notice a lot of false standard holding a lot in your video/thinking.
So many words for "no language standard"
@@Bokto1 Total non response. Linux has already changed C language standard. The first C Unix did not use (at the time) standard C. C++ was not standardized until Linux was 8 years old. also "so many words" and you couldn't respond to any of them.
@@thcrs14 replies, 0 alternative compilers
Do you know how else you can prevent memory leaks? Do not fucking write them.
@@gr4tisfaction that is not a useful or novel bug prevention practice suggestion as everyone is already trying to that and top level programmers understand that rate of bug creation/interaction by any human or it seems for now even AI is not something that can even approach zero. its like someone saying just don't get into an accident in response to the impending adoption of seatbelts. You could discuss as to whether your particular area of driving should require them but just to say that in general is very dmb and just a non response.
What specifically does Rust do that C won’t? Is it capable of something C is not, or does it amount to that the Rust syntax is reputed to lend itself better to certain things?
Apparently it's hard to program C? Or they never learned good programming practices? Those whole debacle smacks of someone saying they don't want to wash their hands after taking a dump.
So it depends on the API and what the end user is trying to do. Two of the big abstractions being rewrite right now are heavily multi threaded. C is clearly not thread safe and can be a pain to get correct. Rust on the other had checks thread safety at compile time so its much easier to work with and be sure you have not introduced any bugs.
@@hahahano2796 Has nothing to do with difficulty. It's more that the history of programming has proven to us over and over again that even the best programmers in the world will make a variety of errors. Linux itself doesn't use "stock" C, they have all sorts of tooling, and wrappers around things to ensure a higher level of safety than what otherwise would be achievable if developers were left to their own devices. Rust is one of many attempts over the years to attempt to mitigate this human failability. There are plenty of ways of getting things wrong or writing insecure code in any language, including rust, but rust's thing is that it forces a higher level of specificity in what you write than other typed languages, enabling the compiler to check for correctness in a way that most other compilers cannot.
Pretty much everything we have been up to in languages for decades one way or another tries to attack that core problem. Look at all the stuff C++ has added, look how libraries like boost, and the stl do things now compared to how it was back in the "C with classes" days. Typeless languages tried to attack it from a totally different angle by taking that control out of the hands of the developer and cleaning up the mess with a GC, etc.
C is elegant and simple, I love C. And it definitely has it's place. But it's also like giving someone a race car with no brakes and then blaming the user that they didn't start to slow down 5 miles before a turn they didn't know about.
@@CommanderRiker0show me The Way, master!
I think the reasonable argument is that Rust is designed for 'big systems', and it is probably true that a modern language with module system and better type system does make it easier to build understandable systems than C. However I'd also argue that trying to retrofit into an already complex C system is the wrong way to go - what exactly are these features that C is implementing that are so hard in Rust - at a guess it is flexible runtime properties that are 'easy' in C because you can just discard type information, whereas that is almost antithetical to Rust.
10 PRINT "Linux v5.0.1"
20 GOTO 10
Ubuntu 25 Rusty Razor
@20:36 Also what better way may be for language to be battle tested than became a part of kernel ? Whatever languge it be, there is no better mine field.
Only risk for Linux kernel i see, is that if thing became more ideological/reliogiius some people will stop contributing.
Kinda concerning when you're (as in the people responsible for the change are) trying to change your preexisting work purely to satisfy something that inherently is unable to work as it stands and has no timeline to do so. It doesn't sound like meritocracy, it sounds more like obsession.
@@Spartan322 Inherently unable to work ?
That sounds like prejudice....
Leave my anime pfp put of this pal
Nobody cares Ash Ketchum
I like rust and its safety, but I think effort ought to be put into defining a standard, making an insanely stable version of the compiler, and then we can use it.
Current rust can be seen as a sandbox, we can look at what works now, we standardise it, get rid of the accumulated crud and go forth with that.
The Ferrous Systems standard is already ISO 26262 and IEC 61508 compliant. While there are talks about putting a standard together the only other front end is still a good ways back(thus wont be used for kernel work for a while as it will have its own issues to solve). When they say stable they are talking about stable, beta and nightly not that the compiler is not stable. Right now they just need to get the ~32 features into stable and not stuck behind feature flags.
The kernel can always be built with past stable releases of rust. It's just the some changes are behind feature flags.
Same. I really don't understand the zealotry associated with this group. The language is neat and all. But the community, sadly, is cringe.
@@justanothercomment416The zealotry is from the C developers who don’t want to have anything to do with it who are actively blocking and keeping abi implementations secret to hinder its introduction
@@justanothercomment416 truly. I just wanna enjoy my nice Rust code without all this drama. If we can't get into the kernel, that's fine! We can work on providing the features, then some day when we're ready we can try again. Just don't be assholes, it's not that hard...
Uuh so Im not a kernel or Rust dev but isnt this just a consequence of the release cycle? If rust support is spotty then no rust patches are going to make it in but that doesnt mean that all that work was done for nothing or that there arent useful changes currently waiting to get in. Wether Rust is actually safer than C can only be told when the compiler is stable but if it is a lot harder to hide unsafe code in rust than c that may really speed up the whole process. Also "Problems in the Kernel" could be Problems that are independent of the existence of Rust.
Stable rust for linux is always 6 months away.
As a Rust user myself, I foresee the 6 months finally coming to an end some time in 2030s
I'm still waiting for the EndTimes OS
Why don't the rust folks just go write their own kernel? Are they trying to SBI their way into Linux to destroy it?
Why do you think anyone is trying to destroy linux? There is no motivation for anyone to do that. They are merely (with Linus's approval) trying to improve the kernel.
They actually have their own kernel (Redox). Interestingly, it looks like a majority of the more vocal Rust promoters don't care about it one bit.
First level of analysis of that would tell us that they care more about trying to "fix" existing software than creating new software. You know, like some kind of "savior" complex.
Second level may indeed suggest that the underlying intent is to destroy Linux or whatever else they "convert" to Rust. I don't know. That may or may not be intentional, but I sure would be extra wary of the major investors behind Rust. Just have a look and tell me if that sounds "trustworthy".
Because that is never gonna be productive. The biggest open source kernel still has hardly any users. Bsd is the runner up and is infinitely less significant. Nothing will be established for a kernel made solely for the programming language. Don't encourage unnecessary fragmentation. Improve what we already have instead
@@nullid1492 It would be when Rust can't even theoretically support ABI stability, a literal requirement for Unix and POSIX. (and not to mention the LGPL)
"Rust folks" already wrote their own kernel. And no, I dont think the goal is to "destroy Linux".
Microsoft also wanted to rewrite some parts of Windows in Rust.
Microsoft gave up on backwards compatibility. They've been taken over by people wanting to do "modern" things and don't care what they break. Linux kernel at least cares about compatibility.
@@username7763quite the contrary, look at the win32-metadata project, where they're documenting the OS API's that they're not just documented books and ancient docs, that have become outdated over the years.
@7:03 I'm not most in too Rust or fur community, but even I know, that at this time stamp youre ranting on things, you have no idea about.
if unstable for you and author of this article means nigthly, then you are mixing meaings.
Nigthly means mainly that things are not accepted standard than they are working wrong.
Also instead of just read that are 29 task of 81 closed, you say about "endless list".
Where there should be zero to even start considering using it for a priject like the kernel.
@@nobiado484I don't think the linux kernel can build without non standard extensions.
It feels odd to say that C can use unstable extensions but Rust can't. Rust is still in the RFC proposal phase you are basically saying the kernel can't have X feature because it's not 100% perfect.
@@nobiado484
Why? Rust still evolves and has robust and well thought practice of introducing new things without special troubles.
And how? How Rust people may know about many things in millions lines kernel without trying to integrate in/with it?
I can bet most of things on this list are for sane or safe integrate with some C quirks or some kernel developers "super smart" tricks.
@@dynfoxx It's not the issue of non standard extensions. You can get the GCC that ships with any distribution and compile your C kernel. You don't need extensions from a wish list, only partially available from a non stable bleading edge version of the compiler.
@@nobiado484 Integrating with the linux kernel is a unique project with some technical requirements not seen in any other software. It is therefore not unreasonable that some changes might be necessary to facilitate it.
Extend.
Google is working on their own kernel. Microsoft wants to stifle progress.
We are experiencing the extend portion of EEE with this.
Fork em.
I heard Google gave up on the new android kernel. I don't follow it close so I may have misheard.
@@mytech6779 last I heard, they are still trying to replace the kernel in Chrome OS
@@madstork91 Seems like a strange waste of resources for a tiny market.
@@mytech6779 It's a growing market. And one that has made a lot of progress in the past year towards running windows programs on linux.
Why are they so determined to use Rust in the Linux kernel? Why not go for the Hurd or something, if they really want to further software development?
No one is using the Hurd. That's a joke.
@@eat.a.dick.google It's not a joke. They tried to implement a pure microkernel, after Apple tried, and came to realise it needs to be hybridised. Either way, the Hurd definitely needs the help.
Obviously this means we need to throw out Rust, and implement Lisp in the Linux kernel
From what I have seen it doesn't even look like a good language for the job.
It has more the characteristics of an application language, or anything else self-contained and non-interfacing.
Agreed. Not sure why Linus likes it so much. As far as system languages is concerned, Zig is far better suited for kernel development as it is essentially a better C (it can even compile C directly), although it is even less stable than Rust.
@@lolilollolilol7773Zigooners dont even have a chance 😂
@20:27 How do you know that ? I'm may bet that kernel is full of strange strucutres and incosistent API's wich are maybe battle tested, but are pain for any new person who must learn to walk around them, so doesn't matter if it Rust or C developers push to make things straight, it will benefit all.
making something more "beatiful" doesn't benefit anyone.
those structures or whatever are like that probably for a reason, and done by smart people.
if Rust cannot figure how to work with that, but asks that to be changed, it just begs for more issues and security vulnerabilities.
You are basically asking for some battle tested things to be rewritten into something that won't be battle tested (and no rust, being a "memory safe" language does not guarantee that you will get anything like that in the end - memory safety is just one segment of good stable code).
@@marsovac it is not about beauty. In big, long projects reason why things are as they are is often long gone and new person trying to understand it may have a fresh look, worth of considering. I'm not asking for changes just because of Rust, every change should be carefully considered, by those vwry smart poeople.
I don't think that anybody wanted rewrite at this time.
Not when its not ABI stable.
@@Spartan322 In kernel you must use C ABI anway for any public functions, so i don't get this argument.
@@AK-vx4dy ABI stability matters more then public functions, but Rust also sucks at that anyway.
GIRL FIGHT !
My guess is that the reason big tech wants Rust in the Linux Kernel is because the people running big tech (Government Intelligence Community) have their fingers in Rust and have it compromised enough that they can use it to compromise the Linux Kernel itself under the guise of, "More Secure".
This ☝️ is the reason source bootstrap-bility matters.
Love it or hate it, we'd all be fascinated to lean how this open source compiler is compromised. Perhaps you could give a code sample that outputs some 'compromised' assembly? Or point to a line of the compiler that is 'compromised'?
If this is not the case, then this is a conspiracy theory.
@@nullid1492
Proving assembly is compromised is non-trivial, proving that source code is compromised in a toolchain that cannot be source bootstrap is meaningless.
@@nullid1492 It may well be but compromising binaries via malicious hidden compiler code (i.e. code that no longer appears in the compiler source) is NOT a fantasy.
@@secretchefcollective444 this is technically correct. However why wouldn't someone compromise clang / gcc using the same technique (given that C++ is so much more popular)?
I'm getting strong Bitcoin vs Ethereum vibes.
Please dont attack the people who enjoys anime just because theres an overlap between them and rust developers. Be a good journalist and stay professional
stay mad, weeb
Please don't misuse "attack",. Be a good person and stay accurate.
@@mytech6779 I believe the wording is accurate, I am no English native so I'm not going to contest it however. Feel free to suggest a more appropriate term if you like to. Whatever that works to help the creator improve their content
@@le0t0rr3z Razz or rib would be accurate terms. Attack is much too strong.
But attacking anime IS the professional thing to do
Do you remember Blitz basic😮
hey, I don't appreciate your tone here at 20:40
I for one, could not care less about rust for linux for now, I'll probably start caring when rust starts breaking the kernels I'm running
That was just a L take on his part, see several comments above yours, people with anime profile pics who wear cat ears are welcome in C userbase (notice that there is no such a thing as "C community")
- sincerely, c enjoyers gang, degenerate front.
This makes me happy, idk why, but it just does. Couldn’t have happened to o a better group of people. 😂
So they're treating Rust like they treat their sexuality. It has to be shoved into everything possible because it's basically their religion.
Medications. Take them.
@@RustIsWinning I can't help but laugh at how your name proves me right.
@@jaysonrees738 I'm laughing at the 🤡 who's parents named their kid Jason but with a Y in the middle of it because they really wanted him to be special LMAO KEK
@@RustIsWinning Your best defense against being called a zealot is a personal attack against the spelling of my name? I'm honestly a little disappointed how that's all you were able to come up with. I don't even feel like I need a proper retort.
@@jaysonrees738 Crying now JaYson Derulo? You laughed at my name and I laughed at yours. Stop being hypocritical. In fact that wasn't a defense because I could not care less. I did not even start my offense but you make it too easy. I know you will whine again lmao