MISS SPOKE: Emacs never charged and I couldn't find the source in which I originally learned this which means I made it up from the cockles of my heart You are welcome and subscribe to me on twitch
As someone from those times, the wars were more substantive then. Machines had very limited memory and disk. vi would start up instantly and was wicked fast, but you only had access to one file at a time, practically no customization, and yeah, modal editing. vi was a huge leap beyond ed, sed, and friends, but not much. Emacs on the other hand was a luxuriant fully customizable and infinitely extensible editor in lisp, but it was a hog of memory and disk, and took forever to start up (relative to vi), and the key bindings were byzantine. Nowadays, both editors are essentially equivalent and the argument is just about the extension language or modal editing. To get the feeling of the old wars, imagine comparing nano to vim ;)
@@liegonPeter here to explain the logic: The type is AbstractChaosFactoryProviderSingleton. This means that the class instance is a singleton and provider of AbstractChaosFactories, which is perfectly valid. Abstract factories do unfortunately exist in the real world.
@@BeatsByYariand to break it down a little more. The provider would be a class most likely passed in as a parameter for dependency injection. Then the class would call the provider (singleton in this case) and create an AbstractChaosFactory. So a factory pattern is used to create many instances of something usually with varying parameters. At this point the class would most likely generate many forms of chaos cast from the abstract base class for chaos. Thusly you have a enterprise scale system capable of many types of chaos and chaos producers.
I've been worried for years about Linux burning to the ground after he dies. He rules with an iron fist, and Linux has been wonderful for me for 18 years now.
@@NGC1433dude, seriously? Maintainer has strong opinions about shit getting in _his_ code base and you have the gall to suggest sarcasm. Go take a long walk off a short pier.
Python is actually too useful and simple for devs to include in Linux. They want something that is impossible to use and no one understands hence; Rust.
I rather get the feeling Prime either is religious or really doesn't want to offend religious people. In Scandinavia (and much of the rest of the Western world) people see religion for what it is: thinly veiled dogmatism.
@@stysner4580 He is pretty religious, from time to time he talks about it on stream. > In scandinavia I guess it depends on the location, from my experience of living in Oslo for a couple years, I would say that norwegians are still pretty religious as a group.
Philosophy is dogmatic. Take one look at the political world, which is all philosophy. Bombs are dropping right now on real people over dogma between old soviet states.
@@stysner4580 "The fool has said in his heart, there is no God." Yes, that's dogmatic, but there is a sense of dogmatism that has to exist. Either God exists or He doesn't. No need to veil it.
I think the argument is that in other languages philosophical/religious has different overlaps than in English and Linus fist language isn't English but Finnish. As a German I can see that some things I would discribe in one way in one language you often should not take it over 1:1 especially phases often don't translate literally
BSD was locked into legal issues during the early 90s, UNIX was expensive and GNU Herd wasn’t ready. Linux was created during a very special five year window and it could not have succeeded five years earlier since GNU wasn’t ready yet and it would have been hard for Linux 0.1 to compete with mature BSD in the late 90s. I also think that Stallman’s philosophy was an inspiration for many young developers.
So that fact that Linus struck gold again with git 15 years later is a fluke right ? He was lucky again ? If the Linux dev structure was not superior it wouldn't have lasted. I used open/net/free bsd in the 2000's with netbsd being my favorite. They did not evolve as fast just because Linus was just better as an engineering lead.
Visual Basic should be used! No type problems there! It won't accept anything bad. If you type the smallest error it gives you POP-UP errors! THAT IS BETTER THAN RUST! Have YOU seen popup-windows in Rust? I didn't think so. Therfore Visual Basic it is!
@@PalladinPoker Sure it sounds bad if you put a negative spin on it. But that goes with rust too. If you omit ANY letter in that declaration you'll get a pop-up error message! Type safety right there, and right in your face. visual basic FORCES you to acknowledge your error by you having to press the "OK" button. The vb editor also refuse to save the file before it is corrected. How in the world could an error be introduced into such a system?
Temple os didn’t even have proper networking, not to even mention the god awful hardware support, yeah most cs students can write small unix clone in a few months but getting to be actually usable takes years.
@@UnidimensionalPropheticCatgirl…. As a year university student in cs who learnt c/c++ on their own years ago, I still help year four students set up mingw…. Or even write make files. My ass can most of these dumbasses write even basic assembly
you should watch what linus said from the source video when its available, reading it from someone else's words gives different interpretation to the intention behind his words.
You have missed the point. The Rust people want the C people to provide precise definitions for the function calls. The C people don't want to do that. I think that the Rust people are right. It's not about whether C is better than Rust.
Is that serious? Rust people can't read C function definition and they want to contribute to kernel? That is funny, I don't know how someone who can't read C function definition can make even simplest kernel API call in any operating system, because all kernel API call in all (to my knowledge) are made by C function calls. Basically any interaction with operating system in any operating systems is done using C function calls (in most cases that is done by standard library) and to do any kernel development reading C function definition is minimal requirement.
@@mrlazda The C definitions are inadequate for a full specification of what to expect. Can objects be null, what is the range of the expected values, for example. The Rust type definitions are much more powerful than C. If that information can't be provided then the interface is fragile.
@@NVM_SMH You are still joking? It is simple in C object cannot be NULL, just because in C there is no objects (C is not object oriented language), you can find range of variables from type ... Rust data types are near identical as C, and Rust is not ADA so you define range of values for variable (ADA was all what Rust promise to be and more but it still failed language, it is still used in some niche areas, but is replaced in it too). All functions are well documented, if they was not, not single program would work and Rust compiler would be useless (even more then useless then is now depends who you ask) because even Rust standard library at end is calling C functions for any kernel API call. If that what you saying is true for Rust programmers the I totally support C programmers and not only that all Rust developers that ask that need to be banned for any access to kernel and they probably should find different profession because software development is not something they know what to do.
@@NVM_SMH Pointer can be NUll or any number in range of 0 to UINTPTR_MAX bit pointer is not object, and can't even point to object, again there is no object in C (C is not object oriented language). And again expected values for parameters are documented for any kernel API function. Maybe Rust programmers can't read documentation? And why Rust programmers would even bother with pointers, they chose Rust because they do not know how to use pointers and deal with raw memory access.
I don't like the idea that C is "easy to learn". It's like saying learning to drive is easy, when what you really mean is "learning how to operate a car is easy". Like yeah, learning the absolute trivial basics of how to operate the thing IS easy, but learning how to do it safely and efficiently is most certainly not. Learning Rust is , I guess, like learning to fly: it's much harder initially, it enforces much stricter safety, and you just plain aren't allowed to do certain things or you won't even be allowed off the ground, and as a result it has a much better safety record.
Learning to program is hard. Full stop. And speaking as someone who has been programming for 40 years (yes I started when I was 10), the language is NOT what makes programming hard. It is understanding the complexity of the interfaces. Rust basically plays keep-away with everything. It's not like learning to fly is to learning to drive. It's like calling an Uber is to learning to drive.
The analogy seems better the other way around. Rust forces you to stay on the ground in order to ensure that you will be safe (e.g. not fall out of the sky). C just lets you do whatever you want, including taking to the skies. It's on you if you pancake yourself.
@@stysner4580 no its limited, so at anypoint you want to do something other than a calculator you suddenly are missing 80% of other programming languages. learning basics + doing some elementary projects isnt learning a language, that takes years, the fact that its so barebones makes it very hard to really get good at building stuff actually useful
Kernel developers being protective and gatekeeping is good for the stability and quality of linux. They should be very skeptical and careful with everything. Linux is a core component of modern civilization.
@@CommanderRiker0They won't create their project for the same reason that rewrites of the applications don't work - the project is already mature and it is impossible to write something that will fully replace it and keep working on the original kernel. You might not like Rust but let's not get stupid - refactors are good even if they are painful
@@computernerd8157 UNIX never really went away… AIX and Solaris are both still sold and get some usage in certain parts of the industry and your networking gear most likely runs on BSD.
Seems to me that the Vi vs Emacs debate is totally different to the C vs Rust debate. In the first case every developer can use whatever editor he likes and it has no effect on any other developer. In the later case if a project adopts a new language then likely everyone has to invest much time and effort into mastering that new language. Worst still they end up having to deal with two languages all the time. I can understand why many have resistance to the demands a new language makes on them
Also since was was emacs the "big paid editor" ?? I don't think that's true at all, I think they have different licenses but I don't think emacs was ever anything more than just stallmans experiments with a lisp compiler, not a big corporate editor VScode
Using C a lot of knowledge is in the heads of developers. Rust sees this reliance on implicit knowledge as a problem and tries to embed a lot of this directly in the type system. To do this, devs not using Rust need to "externalize" some of this knowledge so that the Rust maintainers can build good Rust abstractions. Even if the C maintainers don't have to use Rust, they have to do new things that they didn't have to do earlier to satisfy the builders of the Rust type system. Some of them do not like this.
@@CommanderRiker0Yeah, after all a fully functioning kernel is something that a few guys should be able to build in a few afternoons. That's why we have so many open source kernels to choose from after all. They spring up like js frameworks
@@CommanderRiker0 Linus also suggested someone should write pure Rust kernel, and there are some, for example Redox. But the reason of introducing Rust into Linux is Linus belive the kernel may stagnate if they always doing things the same way and Rust is something that's significantly different and offers clear benifites if it works out. Also it's called an experiment for good reasons.
@@CommanderRiker0”just make a kernel in rust” said by a UA-cam comment. No serious person understanding the landscape of kernel dev believes that’s a good idea. We already have a kernel with decades of effort behind it. How about we don’t replicate all that work because some kernel wizards got butthurt that their API isn’t well defined and Rust devs called them on it.
Sorry, but this is pure entitlement bollocks. The C devs not using Rust have to do exactly nada. They have made abundantly clear they will NOT maintain the Rust bindings. They have made clear, that they don't want to give assurances about any Rust bindings maintained by another person. They WANT to keep things movable instead of turning things into a "well defined" walled garden.
I work on the Tcl core. There is/was a movement to shift development to Rust from C. The issue is that the Rust people who are insisting on that change only want to dick around with memory allocators and such. When confronted with hardware interfaces, external APIs, network communications, etc. they just throw up their hands and say "Oh that's a YOU problem." As if somehow a general purpose scripting language's only job is to allocate memory and not, like INTERFACE with anything.
I find that interesting considering there is not even a standard for using different mem allocators in the Rust standard library, it has been in development for ages. It seems more like Rust people don't care about memory allocations, perhaps the story is totally flipped on the side of #[no_std]
Internal structure is where Rust works best anyway. You say dick around, but they probably just assumed a C interface with the outside world would be best to leave as-is until they fixed most of the other issues in the internals. Dealing with accidentally breaking external interfaces while you still have bugs/issues stemming from a rewrite in the core is not good.
@@stysner4580 Yeah, and they picked the least compatible 'core feature', so much so they're willing to compromise it's CORE functionality in order to do it. Sounds lazy to me.... C devs, got a great language, c, and built an OS out of it. Rust devs got a great language, and is trying to inseminate itself into every possible crevice it can. Correct me if I'm wrong, but did c try to tack onto pascal, or fortran to force some unfitting adaptation?
Zig isn’t a better choice, it’s not different enough from C. There isn’t much benefit from switching, such a big project needs a real good reason to switch to a new language.
The point for Zig that was made is that it ISN'T a direct change at all. You add in some new optional features and QoL. But you don't have to use it if you don't want to.
The problem is just like what you said, it's not a disadvantage. You don't actually need a different language, what you need is a modern C, better C. It's still the kernel world
I would not really say its not unhealthy discusion, sometimes you need to not think about someones feelings, but you need to dish reality check. He is a guy who manage one of the biggest projects with tons of people involved and if he does let everyone do whatever they want, you will end up with disaster. I do not envy Linus.
Watched the interview with Linus and he made a very important point: C in the Linux kernel is not standard C. It has a lot of memory safe code inside, that's (for my understanding) the reason, why he don't' want to force another language.
kernel C is not standard C, but it does not have memory safety built into the language. He said that they've worked to implement memory safety into the kernel, but it's almost impossible to guarantee it with any form of C. Additionally, Linus actively encourages development of Rust in the kernel as he doesn't want the kernel to stay stagnant with C (less and less developers are learning C as time goes on) and sees Rust as the language that most benefits the kernel if it works out due to the memory safety.... which again, Kernel C does not have.
Any example? Like meaningful one? An example of meaningful interface footgun would be struggling to effectively perform a formally called LendingIterator with the std Iterator trait. Spoilers: You can't; because the std iterator is meant to return owned values. Now, if you don't get to learn this limitation to std's Iterator trait, then you might spend hours self-hating yourself for not being able to do a simple Iterator Implementation, when the interface itself wasn't designed to behave like what you were expecting.
Important correction. BSD Unix was open source/free before Linux, BUT it was mired in legal battles for a while. AT&T Unix and derivatives were not free and were not open source. Early in my career commercial Unix (Solaris, IRIX, AIX, HP-UX) dominated the landscape in the semiconductor industry and Linux didn't start to replace them until around 2005 or so.
Miguel Ojeda did not abandon the Rust for Linux project; it was Wedson Almeida Filho. The article is incorrect. I don't know how you can confuse the names; one is Spanish and the other is Brazilian...
Linus gets this stigma of always being a screaming abusive maintainer, but he is not. He's not afraid of calling people out when they are continually making the same mistake, and those always make the news, but the vast majority of the time he is a pretty chill dude.
I love Linus. Not only is he super honest and direct. But he also explained why it's not a valid bug and explains every aspect of it and how they work such as ENOENT and ioctl. That's really professional and I wish this was done more, even forcibly to explain what you don't like and what they thing is. And his last point just saying "screw it, I'll do it myself". Perfect. Makes me miss one of the old CEOs of Nintendo who personally went down and fixed the coding problems.
@@tinrab C is a programming language. Rust is a damn cult. Google: Useful software written Rust. The answer: a pile of web frameworks in the Alpha stage, rewrites of simple Unix utilities (badly) and numerical analysis tools that could have just as easily been written in NumPy or Fortan. Honestly there is more justification of Python or Tcl to have a dedicated kernel module. But they don't need it because they can actually just USE the existing C APIS. Rust is a special case because the design is so broken that the ONLY way to write a potentially useful application is if your entire ecosystem is written in Rust. (And this why when you point out to a Rust Zealot that nothing of any consequence is currently written in Rust will state that "Well once we have a Rust OS..." See. It's a cult.)
For the german string example, the compiler proves more than half of the properties the implementer claims. He can alternatively malloc a Box and just transmute it to whatever he wants, which would be equivalent to what you would do in C, but the compiler would not prove anything about it.
I like how the article mistepresented Linus but you corrected it with hos actual position without watching his full response. If only everybody had BS filter like Prime.
Sometimes mean is necessary to keep the more foolish among us from ruining it for everyone (including themselves). Note: we're all that foolish guy sometimes.
@@hungrymusicwolfare you kidding? His behaviour is completely unnecessary. If somebody bothers you just ban/block them and offer reasonable explanation..or don't. But don't act unhinged. People like you enable low moral character.
Rust bros wanna C wizards to maintain their code. It's Microsoft's inside job to hijack Linux. Tbh Linux doesn't need rust but rust devs need some reason to exist since there's no real world rust jobs.
I know Rust CAN be used to program at the Kernel level but with it's verbose and arcane syntax, it's actually muddying the waters of the kernel! The benefit of C is it's barely above assembly. Keeping the abstraction small. With Rust you're abstracting too far away from the inherent danger of the kernel and adding millions of places for all kinds of problems. Maybe if Linux was built with Rust from the beginning we'd have a different story but trying to mix languages that are almost on opposite ends of the paradigm spectrum together just sounds like problems waiting to happen!
You really should learn a bit of Rust before you comment. C is great, and Kernel C (it's own variant) is even better. But Rust is nothing like what you just said. To begin with, Rust syntax is verbose, but not "arcane". In fact, it's verbosity is specifically there so that you're never confused as to what the code is doing at any point in time. Additionally, Rust doesn't have any sense of "abstraction" over C, other than not having to allocate or free your memory manually. Almost all Rust safety features happen at compile-time checking of your code, not runtime abstractions unlike something like Go with it's garbage collector. Additionally, bindings (especially against a language like C) are pretty standard things and fairly easy to maintain, as long as the functions on either side of the interface are well documented. The only issue here is that the Kernel C code is hard to read, has many layers of abstraction, and are not documented. If any of those 3 things were different, we wouldn't be hearing anything about this issue because it wouldn't be an issue.
...You do understand that kernel code doesn't use plain C though, right? There are a LOT of specific abstractions that are not compile time checks in Linux kernel code. Maintaining all of that and keeping the learning curve small is almost impossible. Maybe that's why Torvalds likes the idea of Rust in the kernel in the first place.
"arcane syntax" ? You feeling okay? Feeling a little blue pilled by Null and memory safety are we. Tony Hoare said it perfectly: "I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."
I try to get back into Rust once in a while and I drop it every time. I hate semantic bureaucracy for stuff that is simple, but Rust doesn't think it is.
@@stysner4580 this is what i think every time c programmres complain about the borrow checker & lifetimes, their code must be full of bugs if that's their gripe with rust
@@Alysonhower Outside of ffi I have never had a Rust panic that wasn't my own fault (edit: logical error, of course 99% of errors are the coder's fault).
I've always understood Zig as the modern C and Rust as the modern C++ so I was super surprised when they announced they were allowing Rust in the kernel
I recommend you simply watch the interview. Linus very politely and calmly made the point that the "memory safety in Rust" versus "Unsafe C in the kernel" debate is a red herring because, as he pointed out, the "C" in the kernel is not the vanilla "C" you usually think of. The "C" in the kernel has been enhanced - especially re memory safety - in decades of work and experience so it's much "memory safer" than the vanilla C because - believe it or not - no kernel developer wants to hunt down ominous memory bugs (even though the Rust community almost gives that impression). Additionally, as Linus pointed out, the kernel gets tested very thorougly in debug builds running with tools like - for instance - Vaögrind that make the claim that the "C" in the kernel is "memory unsafe" not true. There goes your one argument for Rust.
Oh is that why we see breaches all the time?! Maybe think about why Torvalds allowed Rust in the kernel. Maybe he realized maintaining all this stuff that is still wildly unsafe under the hood isn't worth it.
I think Linus is right, it's religious undertones, not philosophical like you said. When discussions heat up and lower passions toss aside rationality, you can't have argumetns, it's just a battle of believes. And thats religious fanatism in a nutshell
"I don't know what Linux did to win from Unix." Long story short, there was a lawsuit between AT&T (SYSV UNIX) and Berkeley (BSD UNIX) over a copyright dispute in the early 90's. BSD ended up winning the lawsuit 4 years later, but these 4 years really weakened the raise of Unix. Meanwhile, Linux was in development which has no ties to Unix at all, and therefore remained unaffected by the lawsuit, and those 4 years were the critical years for Linux to beat Unix.
I think when you said 'you had to pay for emacs', you meant 'you had to pay for vi'. Vi was built on ed which was AT&T licensed, and it remained built on ed until Vim in the early 90s. GNU Emacs was open source from the get-go.
What C has needed is a good way to proof-check code. It's amazing that uninitialized memory and null pointer exceptions are still a thing in any language. Preconditions checked at compile-time, vs violations logged as errors, or causing panics. I was writing Arduino code for months before I realized it was C++ in a wrapper. A checkable subset of C might have avoided this.
@@ZombieLincoln666 though almost no C code is really checked like this. these tools are not part of the language, or any mainstream compiler. i have heard that there is a coq compiler that proves that none of these issues exist. but unfortunately, pointer arithmetic is just part of the language. it's always a hazard. Mojo does lifetimes like Rust, and apparently Mojo fixes some of the issues with Rust lifetimes. it will be interesting to see kernels move to safe-by-default languages.
Freedom from anarchy vs Freedom from authority can be read in two totally different ways. English is just as bad as javascript; and used by about as many people.
I find it easy to categorize confrontations as healthy or unhealthy. Any confrontation that increases the level of understanding of one or both parties is likely to be healthy. The example in which Linus labels code as crap that uses ENOENT as result of an operation working on opened and thus existing files may not be polite, but as much as crap is a useful metaphor for a certain kind of code, this is it. It might be unnecessarily aggressive, but it illustrates how little this code cares for meaningful error messages, something a lot of developers will eventually suffer from. Without Linus' abrasiveness, this suffering might not have been given a voice where it matters. Confrontations about preferences are rarely healthy, because preferences are rarely a result of misunderstandings. Whether you prefer Emacs or VI can be rooted in how you work with your computer, what you do, whether your hands are sensitive to damage from certain movements or just a personal sense of aesthetics. A confrontation about which is better is meaningless if there are no objective quality criteria. I like Linus' confrontational style, assuming that he would back down if he would be in error. I don't know if he does though. I would not like to be on the receiving end of Linus' criticism, but if the mistake was mine, I would appreciate the help and learn. Otherwise I would bark back and loose on a kernel mailing list. That's life and not the worst part of it.
Accomplished C-developer: "I am a master, I know what I'm doing and I need no guardrails" Accomplished Rust-developer: "I acknowledge that humans make mistakes and I am human"
„C Developers will not just turn around and learn Rust“ but nobody is asking them to… they are asked just to talk with the people that can write Rust so the C parts and the rust parts can better work together.
That's not true. What you change, as a C programmer, abstraction on FS subsystem you need to go and ensure all places work as expected. And if the same parts are written in different languages you need to learn a new prg lang because you need to repair all the places not only the C related...
The point of C is 'just enough abstraction of assembly languages'. I would say, C is DSL which generates assembly codes. Some people like driving MT cars while others like AT cars and that is what it is.
That doesn't bode well for C. There was a time when there were still advantages to a MT. But now, the AT is better in every way. MT exists purely for nostalgia reasons.
@@dansanger5340 Not in every way : Automatic gears are more expensive, requires more maintenance, more material at creation. (And from the few I tried you can have big issues, in mountain roads, with engine breaking.)° Basically more complexity in whole lifecycle for so few benefits. In comparison, a oil car is way more complex than a steam car, but the benefits are enormous. Then could we compare C to a steam engine and Rust to a thermic engine ? (by the way, I let you wonder how the steam engine is crucial in our society and is involved in 15% of world total energy).
@@erne75 It's always been better in terms of convenience. Now, it's better in terms of fuel economy and acceleration. And, some car companies now even charge more for manual than automatic.
10:00 Rust as the core of an OS? RedoxOS is exactly that. But it's not really usable for me as a daily-driver as it's just not compatible with my workflow and will probably never really be.
Zig is not an option, specifically because it does not offer any real unique feature good enough for cost of integration. With Rusts safety features and Linux ubiquity, you may literally end up saving lifes by avoiding void pointers. It's also the biggest blind spot so many C fans seem to have. They never ever address how they want to make the Kernel as safe as it would be with Rust. It's all just "skill issue". Well, we've had enough time to see how far that has gotten us.
Yeah I'm laughing at this rust thing because how terribly Linus handled C++. Adopt an ISO standard language with multiple vendors that has facilities for helping write low-level code without incurring a performance or memory cost and still is compatible with C? No, that'd be crazy. But adopt a language owned and run by a single organization that has a single compiler that does add performance costs and requires special bindings to work with C? Sure why not!
@@username7763best part is, they could have just taken C++, strip it down from unneeded features (so it still looks like C/C++), optimize it for kernel use and call it a L language or whatever. Both C and C++ programmers would be happy.
I mean, on the one hand, yea, C technically is simple and you can read the standard quickly, but then you have a lot of time learning all of the pitfalls before you get *good* at C. It seems like Rust has a bit more upfront, but a lot less of the pitfalls later that you have to learn the hard way. And never forget. And never get wrong.
No it's actually not which is why the rust developers are having issues. The only solid boundaries that exist are at userspace. Those are the only sacred boundaries. Everything else is up to be restructured as necessary. I think this is at its core why the rust developers are having so much issue. The language almost requires an unchanging set of interfaces to build upon but the kernel is always changing internally by necessity.
@@greg_land I don't understand this point. Maybe rust developers want some additional guarantees. Because I am sure that right now they also have some dependencies because in the end of the days all components need to interact somehow and communicate with each other. They can't be totally independent from each other or some kernel interfaces
@@greg_land You... literally just described the messiest system ever immediately after saying the kernel is not messy lmao. And you act like Rust can't be "fluid". The issue isn't Rust types or "hard boundaries", the issue is simply that the existing Kernel C code is hard as hell to parse manually if you're not familiar with it. Normally maintainers help people by explaining what each function does. They refuse to do that with the Rust devs, forcing the rust devs to manually parse it to write the bindings. Bindings against C code are fairly easy to write and maintain, as long as you know what data the C functions expects/returns. Keeping the bindings up to date would be trivial if the C code was documented.
It is fitting that when drawing the circle of life at 7:10 C is inside god's circle and Rust is left out of the circles of life entirely. lol Jokes aside, your description of why C vs Rust is such a hot debate is flawless. The only thing is: since they are competing for the same low level code positions, I don't know that there is a nice solution to the dilemma, I think this knife fight will continue indefinitely because order vs anarchy is too fundamental.
Pretty much hit the nail on the head. C developers don't like Rust developers because they think they're coming for their jobs. If C code is replace by Rust, then the C developer has to learn Rust or they're out of a job.
@@Daktyl198 Hard disagree. Even if Rust magically replaced the codebase, you still have to talk to the outside world that's mostly C. They would lose clout and importance but not their job.
@@FathDaniel very little of the world outside of kernels and the lowest level programs use C, and even kernels and those low level programs are slowly being converted to other languages in both macOS and Windows. Linux is actually behind the curve with this, but that’s not new. Linux is ironically much slower to adopt new ideas than macOS or Windows due to its reliance on semi-religious idolatry rather than programmers just following the boss’s orders.
Whether Rust or not, it was a damn moronic decision to bring another language into the kernel. Mixing languages on a project is always a terrible idea, so yes this will fail.
Bindings are nothing new, and Rust can interface with C fairly easily. The only thing is that the developer writing the bindings needs to know both what is needed on the Rust side and the C side. And when the kernel is undocumented kernel-C (special variant of C with extra shit) that has like, 25 layers of abstraction functions before you actually see what something does... sometimes you gotta just ask somebody who knows what it does first before wasting time working it out for yourself.
If you don't understand Algebraic Data Types and their application in clarifying semantics in the data (and subsequently semantics in function design and application) it is difficult to appreciate one of the biggest benefits of Rust - which is also the biggest benefits of all languages that fully support Algebraic Data Types and data semantics.
Ironically, Apple was trying the whole Web-Pages as Applications spiel, long before others did, and now they are the ones behind the times. Yes, Safari is the IE of modern times. The fact that, on mobile devices, Apple is allowed to enforce certain Web-Dev standards to Safari only is a tragedy. It holds mobile Web-App development back by like a decade and devs have to spend extra time and money, just to overcome apples stubbornness.
Regarding Anarchism vs Authoritarian. Even in the Rust community you find that drama. Like Safe Code vs Unsafe Block. I am no web dev but I came across a web crate discussed drama that even made the mainteiner quit because some wanted more safe code than umsafe blocks. I am also not a speed demon myself and more on the safe code side.
True, it seems to me that a lot of people in the rust community are so obsessed with "safety" and "correctedness" that it can get unhealthy sometimes. I feel like there are two kinds of safety, one that is proved by the compiler, and one that is proved by the developer, and it happens quite often that the compiler cannot prove that a certain behaviour is safe, but a developer can with logic, and its perfectly fine to use a safe abstraction over unsafe code in this case, ive done it myself a few times in performance critical applications even though i try to stay away from it, but a lot of people seem to get really hurt by this. maybe they think the compiler is the all knowing oracle - w - (which i wish it was due to the amount of time it takes for it to run)
The issue there is between an experienced Rust developer and an inexperienced one. For some reason, inexperienced developers have this idea that code written in an unsafe block is faster "because it's not checked" but that's not true. The checking happens at compile-time, not during runtime. Code run inside of "unsafe" is not faster, it's merely meant to do things the language would otherwise yell at you for... like creating bindings for unsafe languages like C. There should be very, very few reasons to use the unsafe block in your code unless you're interfacing with other languages.
@@Daktyl198 true. In the Rust forum one made a survey regarding who uses unsafe block for performance. It came as a shock to me that indeed few even do that for performance. But I am still rather new to Rust myself. The up coming Borrow Checker 2.0 will need even fewer unsafe blocks.
@@Daktyl198 well technically unsafe blocks do allow you to bypass some runtime checks, for example, bound checks on slice accesses, which normally would panic if theyre out of bounds, but instead with .get_unchecked results in undefined behaviour, reducing branching, but optimizations made possible by using unsafe blocks are usually not of this kind, it happened once in my case that the compiler couldnt prove the lifetimes of my *very expensive to clone* data, but i could. though, it doesnt seem right to me that even inexperienced rust devs think that the actually expensive checks are done in runtime, the whole point of the language is doing a lot of compile time safety checks
"The most bike-shedding people possible, which is kernel developers" Have you met frontend devs????? Like they spend half their time talking which specific code of conduct to adopt. That is the epitome of bike shedding, it has absolutely nothing to do with code or code performance and guess what everyone has an opinion.
I think one of the things that was missed on the German strings part that nobody else mentioned is that, yes, Rust makes you write more code to achieve the same "effect". But what the Rust code does by nature of you needing to write it out, and the C code almost certainly doesn't, is that you make explicit your design and assumptions. It's not truly 100 lines of Rust vs. 20 lines of C, it's that with 70 lines of explanations in C on top.
For what it's worth, around 2017/2018, Linus took a sabbatical to work on his communication style, and since then he's been much more diplomatic in his criticism! Respect where it's due, he got called out for a toxic communication style, acknowledged the issue, and then made a change!
Ok the take at 6:50 is utter CRAP. Your philosophy is the method by which you contend with the human condition at the deepest level. Your philosophy should inform your religious views, your political views, and even the manner in which you relate to other human beings. Your philosophy dictates your deepest principles, it is how you ground out your beliefs. It is how you justify and understand your moral views. Equating philosophy with politics is absolutely disgusting.
Politics reaches deep into the human brain because we have entire sections of the brain dedicated to its practice, providing data to the rest of the brain all the time. When we imagine our own mind we use the parts of our brain trained on modeling other people's, with all the training it has experienced baked in. I'd love if your take were right, but I don't think the view that philolosophy sits at the deepest level of human experience while politics doesn't is rooted in reality. Both massively shape your deepest principals, beliefs and moral views. Considering 'who we are' is not just the mechanical logic of a brain calculating philosophy but also the mechanical process of the brain that made us social animals doing politics and the emotional processes of an animal exploring the world. Putting them in the same category when examining how people interact with each other and the different ways they approach it seems fairly reasonable.
@@fastestdraw Politics may be a more used pathway/network in the brain. I would expect as much on an average, but most people don't ground out their politics to morals and ethics to philosophy. Philosophy must be the underpinning of a thoroughly investigated worldview. It may take up less brain space, it may have less contact with your conversations, and your interactions with the world. From a reasoning perspective you politics `aught` to be derived soundly from philosophical principles. However I would say this is the case for 1-200 individuals if not less. Most people pick up policies and political alignment based on intuition, or they simply identify with an entire group or party. They align with a political party because that is who their friends and the people they look up to are aligned with. I would never expect a study on the human brain over an average population to reflect what I described above. I also role back the statement on how philosophy effects your relationships, the impact may be profound but likely because of second order effects. For example if your philosophy lead you to being an atheist while your family was very religious. This can have a major impact but again that impact isn't direct. I would also stray from saying that dedicated portions of the brain are used for politics. I think politics would occur in the same portions of the brain as most other higher order information processing. The PFC, the ACC, and a bunch of other places too. I would expect philosophy to use those exact same regions as well, except for some differences, I think philosophy would be more abstract thinking and politics would involve more social and emotional processing. In terms of brain function maybe politics would have more Amygdala use versus more DMN use for philosophy. However that is all very tentative speculation.
@@usershilov Agree on the brain region/function, we do have parts of our brain that seem highly correlated with imagining other minds and predicting their actions, but that is highly unlikely to be the only place in the brain that is happening or the only thing that region does. Couple with both language development and abstract thought appearing to be linked in our evolutionary history, and seperating out philosophy and politics gets even muddier, the comparison between them more apt. Most people aren't sitting around logically reasoning out a philosophy using the building blocks scholars use to describe the world- they are seeking out things and returning to raw experience to see what works - 'is an idea true when I use it in my hands.' The same process is going on with politics. This approach is both fundamentally collaborative, political, sits firmly in that second circle, and results in abstract reasoning derived soundly from the source of philosophical principal - experience. I can't argue that it isn't the practice of philosophy. It grounds out morals ethics politics and yes, philosophy, in a group basis. No man is an island, and neither is our understanding or reasoning. And most people have a deeply explored worldview that doesn't deserve dismissal or disgust because it fails to fit neatly into your world view. If only 1-200 people have done something accessable to 8 billion on the planet presently, I am inclined to think it is a sampling error. But I'm willing to hear out why this 'aught' to still be considered, compare that to my experience, and see if it seems both true and functional.
@@fastestdraw First, I just want to clarify I meant 1 in 200 rather than 1 to 200 people. It is rather rare that people care about epistemology or philosophy. However logically if you question someone on a political view for example abortion. They would provide backing for this perspective by some underlying philosophy. For example by some intrinsic measure all human life deserves a right to life, therefore, abortion should be illegal. Or another who is pro-choice for the first trimester might argue that the rights of small cluster of cells isn't significant rather the collection of organs required to host a conscious human experience is what is valuable and should be protected so only first trimester abortions. You could keep asking for justifications and they would inevitable stall (person doesn't have a developed philosophical world view) or they would provide philosophical justifications. I shouldn't claim any knowledge on how many people have a deeply informed world view. In my experience which may be biased, people don't care, most of the people in my life, are accept a framework of belief from the people around them. I think independent thinkers are rare but on relative scales, there are plenty of us. That doesn't mean that we each should create our own philosophy from scratch, that certainly isn't the case from me. However I do think more people than do should thoroughly consider philosophy. You should have an idea of weather you're a materialist or not, and have some justification for that position, same goes for atheism versus theism. You should consider some of the classical questions of philosophy, and dedicate some time to considering them on your own, try to come up with some method with contending with them, some framework by which to approach them. This is an invaluable pursuit. I think philosophy is necessarily part of a well rounded education. Having explored that part of your worldview you can be much more sure in your positions you can be more confident in your beliefs, you avoid contradictions and cognitive dissonance. I don't think that equating politics with philosophy is disgusting, that was a very hyperbolic statement. I just think that a reasonable person would form their opinions based on some philosophy. I wouldn't say it is necessarily wrong to take the opposite approach; to circle back to the abortion argument maybe intuitively one side makes more sense to you. Then you investigate the the philosophical and moral implications. Based on that investigation you may find that your position has changed maybe not. Either way it is my belief that that investigation 'aught' to be done. I don't think people who have a surface level understanding of politics/philosophy deserve dismissal either. I don't think their political opinions shouldn't be as valuable. I don't think of it as a character flaw, more they don't have the same set of values/interests as me. I care about politics, I care about being able to justify my political positions. I don't care that much about music, and I don't think my position that Post Malone is the greatest artist of all time, should be considered valid. You mention - "seeking out things and returning to raw experience." What do you mean by that, are you saying people seek out bits and pieces of philosophy, which they apply to their daily life? In what ways might someone do that... btw do you have discord?
There was more nuance to the discussion than a rage against Rust. The subsystem maintainer in this instance was just standing up to say, "Im seeing all these new type annotations starting to pop up everywhere in the kernel because of rust... If the rust folks think they need annotations all over the place - well, I'm going to continue my development in C, and I'm sorry to say that I really am not interested in supporting those annotations. If Rust needs the annotations, then someone from the Rust community is going to have to support those annotations."
What about the previous dozens of presentations that were interrupted? Apparently this behavior goes back 20 years. Seems a lot different than a "nuanced discussion".
That is a valid concern and also a valid respond. The real issue is however with how the involved parties talk about their different opinions. Its fine for a c dev to want to continue to program in c, it is a different thing however if the rust team and the c team refuse to collaborate at a basic level when changes to the kernel are made. From what i can gather, the rust team is totally fine with supporting the annotations themselves but they at the very least would like to know when changes to the system are made. I think goes further than "i want to continue to use c" when the rust team only finds out about changes to the system when the code doesnt work anymore.
@@leonardschungel2689 this is not a refusal, C dev are more experienced and know this will not work well. In the purposed solution C dev will not be able to do development without knowing rust, any C change can break rust binding. What they should do? Pair programming? One C and one Rust? And if you think they will be able to do changes separately you are kidding yourself it will be nightmare for Rust and C devs. In order for this to work well you need clear defined boundaries between C and Rust which are not part of the solution.
Love the content! however, as you mentioned, there are difference between Anarchy and Chaos… IMO, Anarchy in C would represents a decentralized yet organized codebase where components interact through clear interfaces without a single controlling entity. This fosters flexibility, maintainability, and collaborative development. Chaos in C would signify a disorganized and unstructured codebase lacking clear boundaries, conventions, and documentation, leading to confusion, bugs, and maintenance challenges. Not sure this is how Linux is management is Chaos… again, jut my opinion.
RE: Linux competitor written in Rust taking over from Linux, no. Language a program is written in has virtually no impact on popularity. For something to overtake Linux, it needs to be better, and not just by a little, there is a threshold that is higher than "actually more for purpose", since there is a yuuuge amount of work to replace OSes, especially for early adopters that basically have to build supporting software as well.
Rust’s ownership and borrowing model introduces a steep learning curve for developers, particularly those already familiar with the relatively simple but powerful memory model of C. For Linux kernel development, where maintaining simplicity and clarity is often prioritized due to the complexity of the system, the added cognitive overhead of managing Rust’s borrow checker could reduce productivity, especially for seasoned C developers. C compilers and toolchains, like GCC and Clang, have been optimized for Linux development across a wide range of architectures, from x86 and ARM to more niche platforms. These toolchains are deeply integrated into the kernel’s build process, and they provide extensive support for the specific needs of kernel development, such as cross-compilation and architecture-specific optimizations. Rust, on the other hand, relies heavily on the LLVM backend, which, while powerful, does not yet match the portability and maturity of GCC when it comes to the diverse hardware supported by Linux. Many embedded systems, for instance, depend on architectures that are not fully supported by Rust. This limits Rust’s suitability for Linux, which runs on an enormous variety of devices, from servers to embedded systems with unique constraints. The reliance on LLVM also creates a dependency that might not be as flexible or future-proof as the existing C toolchain. Additionally, any new toolchain changes could introduce subtle issues or bugs that are difficult to detect in such a large, complex codebase like the Linux kernel.
JS allows to write programs without fully knowing/understanding underlying tech or libraries. Just by having abstract knowledge of what you wanna to achieve and based on experience of working with other libraries/APIs. Which is pretty cool. You need some graph library? OK, here is example of usage, so you will get it working quick. In C, getting it to work quick would not fly. Example is openssl API, which you really need to read every man page for every function you are using. i2d_X509 function, it is literally has "Using a temporary variable is mandatory. A common mistake is to attempt to use a buffer directly as follows..." in docs. "A common mistake"... Instead of designing API, which would not lead to "common mistakes".
There is no drama, it's C programmers who hate commenting their code that are paranoid that Rust will replace them and there is literally no indication of this. Linus has said in Vienna recently IIRC that Rust is an experiment and that he is fully open to going back if it fails, he does not think it has failed. I agree with him.
I could say exactly the same thing about the rust junkies trying to worm their way in somewhere where they are guests and then throw a tantrum because they aren't catered to.
@@Leonhart_93It's so bad that someone tries to add a systemic way to enforce rules that even kernel devs break - look at the linus note to dev trying to use error outside of where it should happen(in this video at the beginning). If it wasn't caught by Linus it would probably be another special case to be remembered... By that logic from now on no one should complain about Rust in the kernel because Linus said that Rust is ok, therefore inviting it and asking for contributions.
apparently a lot of ignorant people do not to that and this seriously angers me , why should other more specific programmers have a expectation of how more ignorant people code , that is what a c vs rust is turning into
Also, Rust is fundamentally unsuited for (pure) kernel development, as the challenges you encounter are inherently unsafe. There's a lot of kernel stuff that you will not be able to do in safe rust. And that's fine, you can still have parts in C and some parts in Rust. Unfortunately, a lot of Rsut-bros completely skim over this fact and try to shove Rust in places where it doesn't belong.
It's so funny to me. The Rust team is focusing so much on pandering to Linux devs for features, prioritizing Linux dev's requests over the other 99% of their userbase. All while Linux devs themselves can't even decide if they want to keep using Rust or not. Please, please, please just let the LInux devs fix their own shit before pandering to them...
@@monsterhunter445the Rust compiler team is focusing on features that Rust for Linux wants rather than anything else, despite Rust for Linux not even being a sure thing. It would be like gcc prioritizing the Linux kernel devs rather than just trying to be a good c compiler
@@SussyBaka-nx4ge Exactly. On Reddit a similar comment got downvoted into the ground by people that didn't know that, with multiple aggressive replies. The Rust community is getting more and more of a cesspool the last couple of years.
Maybe it is also old vs new. The old guys like me, learned coding with machine language that was as close as you can get with hardware. We loved it cause it gave you every freedom and it gave you power as well. Rust is good when it comes to really writing stable code and you don‘t want to care too much about lifetime and memory management (as along as it doesn‘t come to lifetime qualifiers). But on the other hand it limits you in some way (which can be a good thing) and some things happen magically under the hood like with „drop“ - which is good, cause things get cleaned up automatically. But bad, cause it is not so obvious and you have to know about scope. So, it is an interesting discussion. Some interesting problems might show up, when you try to rewrite the complete Linux kernel in Rust.
5:28 "perked out of your mind" is it bad that I originally thought he was talking about percocet? may or may not have binged all of the class of 09s recently
vi vs. Emacs was minimalism vs. everything and the kitchen sink. There were people in university who would do everything inside Emacs, whereas vi users edited code in vi, and used the O/S and commandline for everything else.
“You need 100 lines of Rust to replace 4 lines of C” - sure, but those 100 lines encode all the edge-cases you need to think about like who owns the data, how long it lives for, how it has to be handled etc while in C you get none of that and you have to pray whoever wrote that code has written a 100 line comment above the structure definition
I think the heart of the comment about Linux vs Unix wasn't FOSS vs Closed Source, it was more that if enough people think that it is too difficult to get the features or fixes they want for Linux through the bureaucracy of Linux, they will go and move to somewhere else where they can get those features. Whether that is true or not, remains to be seen, the friction to create a new OS kernel is obviously pretty huge, so there would need to be a lot of discontent. That being said, as Prime pointed out, with Docker and so on, its probably a lot easier to get traction now than when people had to literally install your software on a machine.
It really isn't. C/C++ means you always have work everywhere in the world. If you want to make a lot of money you should learn some of the obscure languages that are still used for very specific things, like Erlang.
MISS SPOKE: Emacs never charged and I couldn't find the source in which I originally learned this which means I made it up from the cockles of my heart
You are welcome and subscribe to me on twitch
You really stepped on a landmine with this one lol.
Takes a lot of patience to talk with so many developers in real time on-stream bro. That's very commendable.
Is miss spoke hot? Let's go
Lucid Emacs charged in the beginning.
As someone from those times, the wars were more substantive then. Machines had very limited memory and disk. vi would start up instantly and was wicked fast, but you only had access to one file at a time, practically no customization, and yeah, modal editing. vi was a huge leap beyond ed, sed, and friends, but not much. Emacs on the other hand was a luxuriant fully customizable and infinitely extensible editor in lisp, but it was a hog of memory and disk, and took forever to start up (relative to vi), and the key bindings were byzantine. Nowadays, both editors are essentially equivalent and the argument is just about the extension language or modal editing. To get the feeling of the old wars, imagine comparing nano to vim ;)
You know it's time to stop when linus says the argument is becoming to toxic
When people say the word "toxic" is when the argument actually ENDS not begins silly pathetic millennial.
If JS is abstract chaos, Java is AbstractChaosFactoryProviderSingleton
goddamn right on the spot joke right there
It's funny, but aren't Singleton and Factory as well as Abstract mutually exclusive?
@@liegonPeter here to explain the logic:
The type is AbstractChaosFactoryProviderSingleton. This means that the class instance is a singleton and provider of AbstractChaosFactories, which is perfectly valid. Abstract factories do unfortunately exist in the real world.
@@BeatsByYari Okay wow, thank you. Seems super unnecessary.
@@BeatsByYariand to break it down a little more.
The provider would be a class most likely passed in as a parameter for dependency injection.
Then the class would call the provider (singleton in this case) and create an AbstractChaosFactory. So a factory pattern is used to create many instances of something usually with varying parameters.
At this point the class would most likely generate many forms of chaos cast from the abstract base class for chaos.
Thusly you have a enterprise scale system capable of many types of chaos and chaos producers.
If Torvalds wasn't the way he is, then Linux would be a terrible experience.
I've been worried for years about Linux burning to the ground after he dies. He rules with an iron fist, and Linux has been wonderful for me for 18 years now.
true
This is deep sarcasm, right? RIGHT???
And that's why I am petrified as to what will happen once he passes/retires...
@@NGC1433dude, seriously? Maintainer has strong opinions about shit getting in _his_ code base and you have the gall to suggest sarcasm. Go take a long walk off a short pier.
why not just use python?
for what?
Best ragebait
Good joke, the door is right there
RUN! :)))))
Python is actually too useful and simple for devs to include in Linux. They want something that is impossible to use and no one understands hence; Rust.
he doesn't mean religious as philosophical, he means religious as dogmatic
Bikeshedding with the analogies
I rather get the feeling Prime either is religious or really doesn't want to offend religious people. In Scandinavia (and much of the rest of the Western world) people see religion for what it is: thinly veiled dogmatism.
@@stysner4580 He is pretty religious, from time to time he talks about it on stream.
> In scandinavia
I guess it depends on the location, from my experience of living in Oslo for a couple years, I would say that norwegians are still pretty religious as a group.
Philosophy is dogmatic. Take one look at the political world, which is all philosophy. Bombs are dropping right now on real people over dogma between old soviet states.
@@stysner4580 "The fool has said in his heart, there is no God."
Yes, that's dogmatic, but there is a sense of dogmatism that has to exist. Either God exists or He doesn't. No need to veil it.
6:25 Telling Linus Torvalds what he actually meant to say is pretty ballsy for a guy who can’t read 👀
Boom, roasted!
ha
I think the argument is that in other languages philosophical/religious has different overlaps than in English and Linus fist language isn't English but Finnish. As a German I can see that some things I would discribe in one way in one language you often should not take it over 1:1 especially phases often don't translate literally
@@thetj8243 oh I didn’t know Linus’ first language was Finnish… still though, I think he’s got a pretty good grasp of English too
"the most bikeshedding group of people which is kernel development" Prime clearly hasn't seen any of the Wayland protocol discussions
Nah Wayland dev is such a shit show 😂
Are they discussions or debates? I think we need to be sure not to misrepresent the kind of communication taking place
BSD was locked into legal issues during the early 90s, UNIX was expensive and GNU Herd wasn’t ready. Linux was created during a very special five year window and it could not have succeeded five years earlier since GNU wasn’t ready yet and it would have been hard for Linux 0.1 to compete with mature BSD in the late 90s. I also think that Stallman’s philosophy was an inspiration for many young developers.
Uh you wrote a comment without finishing it and put a literal ellipsis character at the end. are you okay? Or is youtube fucking with me right now.
Linus fucked up with the GPL but I understand why he had to do it. BSD is the libertarian's licence. GPL is for commies.
@@dc443 its perfectly fine.
2025 the year of Hurd desktop.
So that fact that Linus struck gold again with git 15 years later is a fluke right ? He was lucky again ? If the Linux dev structure was not superior it wouldn't have lasted. I used open/net/free bsd in the 2000's with netbsd being my favorite. They did not evolve as fast just because Linus was just better as an engineering lead.
Visual Basic should be used! No type problems there! It won't accept anything bad. If you type the smallest error it gives you POP-UP errors! THAT IS BETTER THAN RUST! Have YOU seen popup-windows in Rust? I didn't think so. Therfore Visual Basic it is!
Then we can just have an small embedded microkernel inside the Linux kernel(!) to handle window popups for Visual Basic. LGTM let's do it
Truly a psychopath
on error resume next - will never crash
x = 0
Woah man, way too terse.
int x = 0;
no no no, nobody understands that.
DIMENSION x AS INTEGER INITIALLY 0;
now this, this is perfect.
@@PalladinPoker Sure it sounds bad if you put a negative spin on it. But that goes with rust too. If you omit ANY letter in that declaration you'll get a pop-up error message! Type safety right there, and right in your face. visual basic FORCES you to acknowledge your error by you having to press the "OK" button. The vb editor also refuse to save the file before it is corrected. How in the world could an error be introduced into such a system?
Prime: Making an OS takes many many people and many many years
Terry Davis: *enters the chat* (from heaven)
Re-write Linux in HollyC. With the power of god on your side, it has to be safer than Rust.
Temple os didn’t even have proper networking, not to even mention the god awful hardware support, yeah most cs students can write small unix clone in a few months but getting to be actually usable takes years.
@@UnidimensionalPropheticCatgirl how dare you
@@UnidimensionalPropheticCatgirl…. As a year university student in cs who learnt c/c++ on their own years ago, I still help year four students set up mingw…. Or even write make files. My ass can most of these dumbasses write even basic assembly
you should watch what linus said from the source video when its available, reading it from someone else's words gives different interpretation to the intention behind his words.
You have missed the point. The Rust people want the C people to provide precise definitions for the function calls. The C people don't want to do that. I think that the Rust people are right. It's not about whether C is better than Rust.
Is that serious? Rust people can't read C function definition and they want to contribute to kernel? That is funny, I don't know how someone who can't read C function definition can make even simplest kernel API call in any operating system, because all kernel API call in all (to my knowledge) are made by C function calls. Basically any interaction with operating system in any operating systems is done using C function calls (in most cases that is done by standard library) and to do any kernel development reading C function definition is minimal requirement.
@@mrlazda The C definitions are inadequate for a full specification of what to expect. Can objects be null, what is the range of the expected values, for example. The Rust type definitions are much more powerful than C. If that information can't be provided then the interface is fragile.
@@NVM_SMH You are still joking? It is simple in C object cannot be NULL, just because in C there is no objects (C is not object oriented language), you can find range of variables from type ... Rust data types are near identical as C, and Rust is not ADA so you define range of values for variable (ADA was all what Rust promise to be and more but it still failed language, it is still used in some niche areas, but is replaced in it too). All functions are well documented, if they was not, not single program would work and Rust compiler would be useless (even more then useless then is now depends who you ask) because even Rust standard library at end is calling C functions for any kernel API call.
If that what you saying is true for Rust programmers the I totally support C programmers and not only that all Rust developers that ask that need to be banned for any access to kernel and they probably should find different profession because software development is not something they know what to do.
@@mrlazda can the pointer be null. What are the expected values for parameters.
@@NVM_SMH Pointer can be NUll or any number in range of 0 to UINTPTR_MAX bit pointer is not object, and can't even point to object, again there is no object in C (C is not object oriented language). And again expected values for parameters are documented for any kernel API function.
Maybe Rust programmers can't read documentation?
And why Rust programmers would even bother with pointers, they chose Rust because they do not know how to use pointers and deal with raw memory access.
I don't like the idea that C is "easy to learn". It's like saying learning to drive is easy, when what you really mean is "learning how to operate a car is easy". Like yeah, learning the absolute trivial basics of how to operate the thing IS easy, but learning how to do it safely and efficiently is most certainly not.
Learning Rust is , I guess, like learning to fly: it's much harder initially, it enforces much stricter safety, and you just plain aren't allowed to do certain things or you won't even be allowed off the ground, and as a result it has a much better safety record.
Learning to program is hard. Full stop. And speaking as someone who has been programming for 40 years (yes I started when I was 10), the language is NOT what makes programming hard. It is understanding the complexity of the interfaces.
Rust basically plays keep-away with everything. It's not like learning to fly is to learning to drive. It's like calling an Uber is to learning to drive.
But it is easy to learn. It is limited, therefore it is both easy to learn and hard to use.
The analogy seems better the other way around. Rust forces you to stay on the ground in order to ensure that you will be safe (e.g. not fall out of the sky). C just lets you do whatever you want, including taking to the skies. It's on you if you pancake yourself.
@@stysner4580 no its limited, so at anypoint you want to do something other than a calculator you suddenly are missing 80% of other programming languages. learning basics + doing some elementary projects isnt learning a language, that takes years, the fact that its so barebones makes it very hard to really get good at building stuff actually useful
No way anybody who is competent would claim that C is easy to learn
Kernel developers being protective and gatekeeping is good for the stability and quality of linux. They should be very skeptical and careful with everything. Linux is a core component of modern civilization.
@@CommanderRiker0They won't create their project for the same reason that rewrites of the applications don't work - the project is already mature and it is impossible to write something that will fully replace it and keep working on the original kernel.
You might not like Rust but let's not get stupid - refactors are good even if they are painful
@@CommanderRiker0 there is RedoxOS but a lot of modern stuff wouldint work
The world can survive if Linux dies, just like it did when Unix went away.
@@computernerd8157 UNIX never really went away… AIX and Solaris are both still sold and get some usage in certain parts of the industry and your networking gear most likely runs on BSD.
With Linus being the most protective of them all, and he despite multiple dramas is still optimistic about Rust. That says a lot.
Me binding every function in Linux to Squirrel so I can replace bash scripts with nuts.
Does it use Squirrely braces?
Deez Nuts
@@KelvinShadewing LOL the classic .🌰 files :D
That's just nuts!
Let's go more linux drama
Seems to me that the Vi vs Emacs debate is totally different to the C vs Rust debate. In the first case every developer can use whatever editor he likes and it has no effect on any other developer. In the later case if a project adopts a new language then likely everyone has to invest much time and effort into mastering that new language. Worst still they end up having to deal with two languages all the time. I can understand why many have resistance to the demands a new language makes on them
Also since was was emacs the "big paid editor" ?? I don't think that's true at all, I think they have different licenses but I don't think emacs was ever anything more than just stallmans experiments with a lisp compiler, not a big corporate editor VScode
@@aibrainlet8041so that's a woosh
@@yjlom ??
@@aibrainlet8041 en.m.wikipedia.org/wiki/Joke
@@yjlomthat indeed wasn't a woosh sir
Using C a lot of knowledge is in the heads of developers. Rust sees this reliance on implicit knowledge as a problem and tries to embed a lot of this directly in the type system. To do this, devs not using Rust need to "externalize" some of this knowledge so that the Rust maintainers can build good Rust abstractions. Even if the C maintainers don't have to use Rust, they have to do new things that they didn't have to do earlier to satisfy the builders of the Rust type system. Some of them do not like this.
@@CommanderRiker0Yeah, after all a fully functioning kernel is something that a few guys should be able to build in a few afternoons. That's why we have so many open source kernels to choose from after all. They spring up like js frameworks
@@CommanderRiker0 Linus also suggested someone should write pure Rust kernel, and there are some, for example Redox. But the reason of introducing Rust into Linux is Linus belive the kernel may stagnate if they always doing things the same way and Rust is something that's significantly different and offers clear benifites if it works out. Also it's called an experiment for good reasons.
@@CommanderRiker0W take.
@@CommanderRiker0”just make a kernel in rust” said by a UA-cam comment. No serious person understanding the landscape of kernel dev believes that’s a good idea.
We already have a kernel with decades of effort behind it. How about we don’t replicate all that work because some kernel wizards got butthurt that their API isn’t well defined and Rust devs called them on it.
Sorry, but this is pure entitlement bollocks.
The C devs not using Rust have to do exactly nada. They have made abundantly clear they will NOT maintain the Rust bindings. They have made clear, that they don't want to give assurances about any Rust bindings maintained by another person. They WANT to keep things movable instead of turning things into a "well defined" walled garden.
I work on the Tcl core. There is/was a movement to shift development to Rust from C. The issue is that the Rust people who are insisting on that change only want to dick around with memory allocators and such. When confronted with hardware interfaces, external APIs, network communications, etc. they just throw up their hands and say "Oh that's a YOU problem."
As if somehow a general purpose scripting language's only job is to allocate memory and not, like INTERFACE with anything.
I find that interesting considering there is not even a standard for using different mem allocators in the Rust standard library, it has been in development for ages. It seems more like Rust people don't care about memory allocations, perhaps the story is totally flipped on the side of #[no_std]
Internal structure is where Rust works best anyway. You say dick around, but they probably just assumed a C interface with the outside world would be best to leave as-is until they fixed most of the other issues in the internals. Dealing with accidentally breaking external interfaces while you still have bugs/issues stemming from a rewrite in the core is not good.
It's almost as if they have less manpower and want to start at some core feature so they can build from there.
Crazy, I know.
@@stysner4580 Yeah, and they picked the least compatible 'core feature', so much so they're willing to compromise it's CORE functionality in order to do it. Sounds lazy to me....
C devs, got a great language, c, and built an OS out of it. Rust devs got a great language, and is trying to inseminate itself into every possible crevice it can.
Correct me if I'm wrong, but did c try to tack onto pascal, or fortran to force some unfitting adaptation?
@@wetter4293 Nope, C just did what it does and didn't need zealots shoveling it down everyone's throats.
Zig isn’t a better choice, it’s not different enough from C. There isn’t much benefit from switching, such a big project needs a real good reason to switch to a new language.
The point for Zig that was made is that it ISN'T a direct change at all. You add in some new optional features and QoL. But you don't have to use it if you don't want to.
The problem is just like what you said, it's not a disadvantage. You don't actually need a different language, what you need is a modern C, better C. It's still the kernel world
Who is talking about switching?
I would not really say its not unhealthy discusion, sometimes you need to not think about someones feelings, but you need to dish reality check. He is a guy who manage one of the biggest projects with tons of people involved and if he does let everyone do whatever they want, you will end up with disaster. I do not envy Linus.
Watched the interview with Linus and he made a very important point: C in the Linux kernel is not standard C. It has a lot of memory safe code inside, that's (for my understanding) the reason, why he don't' want to force another language.
Cool. It is still memory unsafe tho 😂
kernel C is not standard C, but it does not have memory safety built into the language. He said that they've worked to implement memory safety into the kernel, but it's almost impossible to guarantee it with any form of C. Additionally, Linus actively encourages development of Rust in the kernel as he doesn't want the kernel to stay stagnant with C (less and less developers are learning C as time goes on) and sees Rust as the language that most benefits the kernel if it works out due to the memory safety.... which again, Kernel C does not have.
Why do you idiots keep saying "he doesn't want another language" when he signed off on and is still supporting Rust in the kernel?!
@@RustIsWinning so is “safe” rust, thanks to all the UBs surrounding closures and lifetime expansion.
Any example? Like meaningful one? An example of meaningful interface footgun would be struggling to effectively perform a formally called LendingIterator with the std Iterator trait.
Spoilers: You can't; because the std iterator is meant to return owned values. Now, if you don't get to learn this limitation to std's Iterator trait, then you might spend hours self-hating yourself for not being able to do a simple Iterator Implementation, when the interface itself wasn't designed to behave like what you were expecting.
Important correction. BSD Unix was open source/free before Linux, BUT it was mired in legal battles for a while. AT&T Unix and derivatives were not free and were not open source. Early in my career commercial Unix (Solaris, IRIX, AIX, HP-UX) dominated the landscape in the semiconductor industry and Linux didn't start to replace them until around 2005 or so.
Miguel Ojeda did not abandon the Rust for Linux project; it was Wedson Almeida Filho. The article is incorrect. I don't know how you can confuse the names; one is Spanish and the other is Brazilian...
Linus gets this stigma of always being a screaming abusive maintainer, but he is not. He's not afraid of calling people out when they are continually making the same mistake, and those always make the news, but the vast majority of the time he is a pretty chill dude.
I love Linus.
Not only is he super honest and direct. But he also explained why it's not a valid bug and explains every aspect of it and how they work such as ENOENT and ioctl.
That's really professional and I wish this was done more, even forcibly to explain what you don't like and what they thing is.
And his last point just saying "screw it, I'll do it myself". Perfect. Makes me miss one of the old CEOs of Nintendo who personally went down and fixed the coding problems.
Agreed.
Chaos is not Anarchy, it is Anomy. Anarchy is order but without a Ruler. Anomy is chaos without a Ruler.
haha, accurate!
"Torvalds doesn't get it: Rust isn't a religion, it's a philosophy" - The Primeagen 2024
Its a cult. Cargo Cult.
@@tinrab C is a programming language. Rust is a damn cult. Google: Useful software written Rust. The answer: a pile of web frameworks in the Alpha stage, rewrites of simple Unix utilities (badly) and numerical analysis tools that could have just as easily been written in NumPy or Fortan.
Honestly there is more justification of Python or Tcl to have a dedicated kernel module. But they don't need it because they can actually just USE the existing C APIS. Rust is a special case because the design is so broken that the ONLY way to write a potentially useful application is if your entire ecosystem is written in Rust.
(And this why when you point out to a Rust Zealot that nothing of any consequence is currently written in Rust will state that "Well once we have a Rust OS..." See. It's a cult.)
@@DataPastorI always assumed that was the joke tbh ...
@@DataPastor You did watch the video right? Where Torvalds was talking about both sides of the argument, not just Rust devs? You're not helping.
@@stysner4580 they call rust a cult then blindly defend their favorite language, its really funny to watch
They should name this the "Blue Hair War" (for those that remember when their grandma had blue hair)
You can still make memory problems in javascript
The same goes for Rust. The same goes for C#. The same goes for ANY language. Leaking memory is trivially easy to do.
Yes, even Prime made a video on it. It's ridiculously easy to leak memory with globals in JS.
For the german string example, the compiler proves more than half of the properties the implementer claims. He can alternatively malloc a Box and just transmute it to whatever he wants, which would be equivalent to what you would do in C, but the compiler would not prove anything about it.
Would you mind elaborating on this point? How can the compiler help by knowing something is a German string? Thanks!
I like how the article mistepresented Linus but you corrected it with hos actual position without watching his full response. If only everybody had BS filter like Prime.
I'd say this. Linus is mean, but not toxic. Which I think is the aspect some people miss.
Sometimes mean is necessary to keep the more foolish among us from ruining it for everyone (including themselves).
Note: we're all that foolish guy sometimes.
Many cultures prefer politeness over honesty. They're wrong.
@@hungrymusicwolf Man, I'm a foolish guy all the time
@@hungrymusicwolfare you kidding? His behaviour is completely unnecessary. If somebody bothers you just ban/block them and offer reasonable explanation..or don't. But don't act unhinged. People like you enable low moral character.
@@hungrymusicwolfit’s not necessary
I think the rust people aren't asking for c devs to change. They're asking for c devs to define the behaviour and they don't want to
Sshhh let them strawman, it's their only way to cope.
They never had to before. Spit and a prayer has always been enough after all
Rust bros wanna C wizards to maintain their code. It's Microsoft's inside job to hijack Linux. Tbh Linux doesn't need rust but rust devs need some reason to exist since there's no real world rust jobs.
Reading the C code does not lead to the definition of the behavior, because C has UB.
@Dredge22 professional C writer are you?
I know Rust CAN be used to program at the Kernel level but with it's verbose and arcane syntax, it's actually muddying the waters of the kernel! The benefit of C is it's barely above assembly. Keeping the abstraction small. With Rust you're abstracting too far away from the inherent danger of the kernel and adding millions of places for all kinds of problems. Maybe if Linux was built with Rust from the beginning we'd have a different story but trying to mix languages that are almost on opposite ends of the paradigm spectrum together just sounds like problems waiting to happen!
You really should learn a bit of Rust before you comment. C is great, and Kernel C (it's own variant) is even better. But Rust is nothing like what you just said. To begin with, Rust syntax is verbose, but not "arcane". In fact, it's verbosity is specifically there so that you're never confused as to what the code is doing at any point in time. Additionally, Rust doesn't have any sense of "abstraction" over C, other than not having to allocate or free your memory manually. Almost all Rust safety features happen at compile-time checking of your code, not runtime abstractions unlike something like Go with it's garbage collector.
Additionally, bindings (especially against a language like C) are pretty standard things and fairly easy to maintain, as long as the functions on either side of the interface are well documented. The only issue here is that the Kernel C code is hard to read, has many layers of abstraction, and are not documented. If any of those 3 things were different, we wouldn't be hearing anything about this issue because it wouldn't be an issue.
...You do understand that kernel code doesn't use plain C though, right? There are a LOT of specific abstractions that are not compile time checks in Linux kernel code. Maintaining all of that and keeping the learning curve small is almost impossible. Maybe that's why Torvalds likes the idea of Rust in the kernel in the first place.
"arcane syntax" ? You feeling okay? Feeling a little blue pilled by Null and memory safety are we. Tony Hoare said it perfectly:
"I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."
@@71Jay17 references and nullability is perfectly fine, i'm not sure how people struggle with it so much
big w take here, this is totally a philosophical argument on how software should be designed/written.
I try to get back into Rust once in a while and I drop it every time. I hate semantic bureaucracy for stuff that is simple, but Rust doesn't think it is.
same. love hate relationship
Isn't the problem that people have made themselves believe stuff is simple when it is very much not so? That's literally the reason for Rust existing.
@@stysner4580 this is what i think every time c programmres complain about the borrow checker & lifetimes, their code must be full of bugs if that's their gripe with rust
Wrap everything with unwrap() or expect("this should work, good look debugging it, bye") and you're done.
@@Alysonhower Outside of ffi I have never had a Rust panic that wasn't my own fault (edit: logical error, of course 99% of errors are the coder's fault).
I've always understood Zig as the modern C and Rust as the modern C++ so I was super surprised when they announced they were allowing Rust in the kernel
C++26 is the modern C++.
The reason is that Zig doesn't have sufficient memory satefy mechanisms.
Zig wasn’t (and still probably isn’t) mature enough two years ago when they decided to adopt rust
@@wqlee it's good enough imo
@@wqleereally? i thought it was because andrew wanted to do breaking changes to the language still to get the syntax just right.
I recommend you simply watch the interview. Linus very politely and calmly made the point that the "memory safety in Rust" versus "Unsafe C in the kernel" debate is a red herring because, as he pointed out, the "C" in the kernel is not the vanilla "C" you usually think of. The "C" in the kernel has been enhanced - especially re memory safety - in decades of work and experience so it's much "memory safer" than the vanilla C because - believe it or not - no kernel developer wants to hunt down ominous memory bugs (even though the Rust community almost gives that impression). Additionally, as Linus pointed out, the kernel gets tested very thorougly in debug builds running with tools like - for instance - Vaögrind that make the claim that the "C" in the kernel is "memory unsafe" not true.
There goes your one argument for Rust.
So many tools, mitigations and static analyzers and yet you still end up with critical CVEs LOL
@@RustIsWinningRust community is a cult
@@RustIsWinning No programming language is perfect, not even Rust.
Oh is that why we see breaches all the time?! Maybe think about why Torvalds allowed Rust in the kernel. Maybe he realized maintaining all this stuff that is still wildly unsafe under the hood isn't worth it.
@@stysner4580 vulnerabilities in the kernel are rarely related to memory bugs and even more rarely to the ones rust manages to prevent.
I love that low level learning is just in the chat, dropping truth bombs
I think Linus is right, it's religious undertones, not philosophical like you said. When discussions heat up and lower passions toss aside rationality, you can't have argumetns, it's just a battle of believes. And thats religious fanatism in a nutshell
That's ironically only true if you're indoctrinated into the post-modern liberal religion that defines terms in such a dishonest way
"I don't know what Linux did to win from Unix."
Long story short, there was a lawsuit between AT&T (SYSV UNIX) and Berkeley (BSD UNIX) over a copyright dispute in the early 90's.
BSD ended up winning the lawsuit 4 years later, but these 4 years really weakened the raise of Unix.
Meanwhile, Linux was in development which has no ties to Unix at all, and therefore remained unaffected by the lawsuit, and those 4 years were the critical years for Linux to beat Unix.
We've got software development racism before GTA 6 💀
I legally declare that I am Rustist.
we had that way before windows even existed. c was initially scoffed for being too high level by the assembly people
If Bun is a large project in Zig then Deno is a large project in Rust.
I admit, I thought "Squeal" for sql, "Gson" for json are kinda cute, but "Vy" for Vi is too much!!
How about Vee?
@@ThePrimeTimeagen Ah VEE, the visual programming environment for measurement devices.
@@ThePrimeTimeagen It's "vee eye" you philistine.
WTF this one is how people actually pronounce Vi… At least John Carmack does.
@@max_talks_42oh right, as if you pronounce it vee eye em. Vay and vim are great editors. Cope harder :3
I think when you said 'you had to pay for emacs', you meant 'you had to pay for vi'. Vi was built on ed which was AT&T licensed, and it remained built on ed until Vim in the early 90s. GNU Emacs was open source from the get-go.
This is Scandinavia couture we just Shit on each other and this just means Love
What C has needed is a good way to proof-check code. It's amazing that uninitialized memory and null pointer exceptions are still a thing in any language. Preconditions checked at compile-time, vs violations logged as errors, or causing panics. I was writing Arduino code for months before I realized it was C++ in a wrapper. A checkable subset of C might have avoided this.
C has tons of tools for that
@@ZombieLincoln666 though almost no C code is really checked like this. these tools are not part of the language, or any mainstream compiler. i have heard that there is a coq compiler that proves that none of these issues exist. but unfortunately, pointer arithmetic is just part of the language. it's always a hazard. Mojo does lifetimes like Rust, and apparently Mojo fixes some of the issues with Rust lifetimes. it will be interesting to see kernels move to safe-by-default languages.
Freedom from anarchy vs Freedom from authority can be read in two totally different ways.
English is just as bad as javascript; and used by about as many people.
intelligent people talking about anarchism without ever having done deep reading on anarchism always makes me sad
I don't know what you're on about implying Torvalds is abrasive. He's the least direct Finnish person.
I use javascript to make drivers
I use css. COBOL style sheets
@@JabberwockybirdGood one
I find it easy to categorize confrontations as healthy or unhealthy. Any confrontation that increases the level of understanding of one or both parties is likely to be healthy. The example in which Linus labels code as crap that uses ENOENT as result of an operation working on opened and thus existing files may not be polite, but as much as crap is a useful metaphor for a certain kind of code, this is it. It might be unnecessarily aggressive, but it illustrates how little this code cares for meaningful error messages, something a lot of developers will eventually suffer from. Without Linus' abrasiveness, this suffering might not have been given a voice where it matters.
Confrontations about preferences are rarely healthy, because preferences are rarely a result of misunderstandings. Whether you prefer Emacs or VI can be rooted in how you work with your computer, what you do, whether your hands are sensitive to damage from certain movements or just a personal sense of aesthetics. A confrontation about which is better is meaningless if there are no objective quality criteria.
I like Linus' confrontational style, assuming that he would back down if he would be in error. I don't know if he does though. I would not like to be on the receiving end of Linus' criticism, but if the mistake was mine, I would appreciate the help and learn. Otherwise I would bark back and loose on a kernel mailing list. That's life and not the worst part of it.
Accomplished C-developer: "I am a master, I know what I'm doing and I need no guardrails"
Accomplished Rust-developer: "I acknowledge that humans make mistakes and I am human"
„C Developers will not just turn around and learn Rust“ but nobody is asking them to… they are asked just to talk with the people that can write Rust so the C parts and the rust parts can better work together.
That's not true. What you change, as a C programmer, abstraction on FS subsystem you need to go and ensure all places work as expected. And if the same parts are written in different languages you need to learn a new prg lang because you need to repair all the places not only the C related...
The point of C is 'just enough abstraction of assembly languages'.
I would say, C is DSL which generates assembly codes.
Some people like driving MT cars while others like AT cars and that is what it is.
That doesn't bode well for C. There was a time when there were still advantages to a MT. But now, the AT is better in every way. MT exists purely for nostalgia reasons.
@@dansanger5340 They need to start putting them in cars then because every AT car I've driven has been a less compelling experience.
@@dansanger5340 Not in every way : Automatic gears are more expensive, requires more maintenance, more material at creation. (And from the few I tried you can have big issues, in mountain roads, with engine breaking.)° Basically more complexity in whole lifecycle for so few benefits. In comparison, a oil car is way more complex than a steam car, but the benefits are enormous.
Then could we compare C to a steam engine and Rust to a thermic engine ? (by the way, I let you wonder how the steam engine is crucial in our society and is involved in 15% of world total energy).
@@dansanger5340define "better"
@@erne75 It's always been better in terms of convenience. Now, it's better in terms of fuel economy and acceleration. And, some car companies now even charge more for manual than automatic.
Now, we're talking about. We wanted to hear your opinion about this. Thanks you created a video for this one.
10:00 Rust as the core of an OS? RedoxOS is exactly that. But it's not really usable for me as a daily-driver as it's just not compatible with my workflow and will probably never really be.
Zig is not an option, specifically because it does not offer any real unique feature good enough for cost of integration. With Rusts safety features and Linux ubiquity, you may literally end up saving lifes by avoiding void pointers.
It's also the biggest blind spot so many C fans seem to have. They never ever address how they want to make the Kernel as safe as it would be with Rust. It's all just "skill issue". Well, we've had enough time to see how far that has gotten us.
modern C++ is the way to go for modern Linux kernel 💪🍤
Linus not like C++
@@cobrab1978 c++ developers don't like c++, life is a confusing symphony
Yeah I'm laughing at this rust thing because how terribly Linus handled C++. Adopt an ISO standard language with multiple vendors that has facilities for helping write low-level code without incurring a performance or memory cost and still is compatible with C? No, that'd be crazy. But adopt a language owned and run by a single organization that has a single compiler that does add performance costs and requires special bindings to work with C? Sure why not!
@@username7763best part is, they could have just taken C++, strip it down from unneeded features (so it still looks like C/C++), optimize it for kernel use and call it a L language or whatever.
Both C and C++ programmers would be happy.
@@username7763 We hate mono cultures, it doesn't scale without any competition. 🤣
I mean, on the one hand, yea, C technically is simple and you can read the standard quickly, but then you have a lot of time learning all of the pitfalls before you get *good* at C. It seems like Rust has a bit more upfront, but a lot less of the pitfalls later that you have to learn the hard way. And never forget. And never get wrong.
The religion analogy: some people believe what they believe regardless of arguments or evidence. That's definitely going on here.
Linux is really messy in terms of architecture. This is like making changes in huge legacy monolith. It's very hard
No it's actually not which is why the rust developers are having issues. The only solid boundaries that exist are at userspace. Those are the only sacred boundaries. Everything else is up to be restructured as necessary. I think this is at its core why the rust developers are having so much issue. The language almost requires an unchanging set of interfaces to build upon but the kernel is always changing internally by necessity.
@@greg_land I don't understand this point. Maybe rust developers want some additional guarantees. Because I am sure that right now they also have some dependencies because in the end of the days all components need to interact somehow and communicate with each other. They can't be totally independent from each other or some kernel interfaces
@@greg_land You... literally just described the messiest system ever immediately after saying the kernel is not messy lmao. And you act like Rust can't be "fluid". The issue isn't Rust types or "hard boundaries", the issue is simply that the existing Kernel C code is hard as hell to parse manually if you're not familiar with it. Normally maintainers help people by explaining what each function does. They refuse to do that with the Rust devs, forcing the rust devs to manually parse it to write the bindings. Bindings against C code are fairly easy to write and maintain, as long as you know what data the C functions expects/returns. Keeping the bindings up to date would be trivial if the C code was documented.
It is fitting that when drawing the circle of life at 7:10 C is inside god's circle and Rust is left out of the circles of life entirely. lol
Jokes aside, your description of why C vs Rust is such a hot debate is flawless. The only thing is: since they are competing for the same low level code positions, I don't know that there is a nice solution to the dilemma, I think this knife fight will continue indefinitely because order vs anarchy is too fundamental.
Pretty much hit the nail on the head. C developers don't like Rust developers because they think they're coming for their jobs. If C code is replace by Rust, then the C developer has to learn Rust or they're out of a job.
@@Daktyl198 Hard disagree. Even if Rust magically replaced the codebase, you still have to talk to the outside world that's mostly C. They would lose clout and importance but not their job.
@@FathDaniel very little of the world outside of kernels and the lowest level programs use C, and even kernels and those low level programs are slowly being converted to other languages in both macOS and Windows. Linux is actually behind the curve with this, but that’s not new. Linux is ironically much slower to adopt new ideas than macOS or Windows due to its reliance on semi-religious idolatry rather than programmers just following the boss’s orders.
Whether Rust or not, it was a damn moronic decision to bring another language into the kernel. Mixing languages on a project is always a terrible idea, so yes this will fail.
My guy has never heard about Android LOL 😂
Bindings are nothing new, and Rust can interface with C fairly easily. The only thing is that the developer writing the bindings needs to know both what is needed on the Rust side and the C side. And when the kernel is undocumented kernel-C (special variant of C with extra shit) that has like, 25 layers of abstraction functions before you actually see what something does... sometimes you gotta just ask somebody who knows what it does first before wasting time working it out for yourself.
@@RustIsWinning android 😂
Internet experts think that they know better than linux kernel devs. Its amusing. The anger against rust is completely justified
@@zzrroott6459 Says the internet expert 🤡 himself. Ironic 🤣🤣🤣
If you don't understand Algebraic Data Types and their application in clarifying semantics in the data (and subsequently semantics in function design and application) it is difficult to appreciate one of the biggest benefits of Rust - which is also the biggest benefits of all languages that fully support Algebraic Data Types and data semantics.
Big ass projects on Rust:
- Servo
- WASI
- Tauri
- Firefox (progressively increasing the share of the code)
- Deno
- Sway (Web3)
- Fuel core
- Pingora (used in Cloudflare)
- Zed (multiplayer text editor)
- SurrealDb (munlti-paradigm database)
- Sonic (search db)
- Cube (data application)
- fnm (fast node manager)
- biome (old rome tools)
- dioxus (fullstack framework)
- gleam (functional programming EVM language)
- helix (neovim succesor)
- neon (serverless postgress)
- OpenGMK (open source GameMaker engine)
- wasmtime (WASM runtime on top of cranelift)
- firecracker (microVMs used for AWS Lambda)
You forgot wgpu
And COSMIC
Bevy the game engine! (Nice list, it's almost like he's saying here that Rust is behind Zig in project count)
@@roan1366 If you don't double-check everything Prime says, are you really listening to what he said?
Huggingface and vllm use rust heavily (local llm inference)
Will Prime ever do a tutorial for Rust, from beginner to expert?
They should just rewrite in Perl 6
Ironically, Apple was trying the whole Web-Pages as Applications spiel, long before others did, and now they are the ones behind the times.
Yes, Safari is the IE of modern times. The fact that, on mobile devices, Apple is allowed to enforce certain Web-Dev standards to Safari only is a tragedy. It holds mobile Web-App development back by like a decade and devs have to spend extra time and money, just to overcome apples stubbornness.
Regarding Anarchism vs Authoritarian. Even in the Rust community you find that drama. Like Safe Code vs Unsafe Block. I am no web dev but I came across a web crate discussed drama that even made the mainteiner quit because some wanted more safe code than umsafe blocks. I am also not a speed demon myself and more on the safe code side.
well we have dangerouslySetInnerHtml
True, it seems to me that a lot of people in the rust community are so obsessed with "safety" and "correctedness" that it can get unhealthy sometimes.
I feel like there are two kinds of safety, one that is proved by the compiler, and one that is proved by the developer, and it happens quite often that the compiler cannot prove that a certain behaviour is safe, but a developer can with logic, and its perfectly fine to use a safe abstraction over unsafe code in this case, ive done it myself a few times in performance critical applications even though i try to stay away from it, but a lot of people seem to get really hurt by this. maybe they think the compiler is the all knowing oracle - w - (which i wish it was due to the amount of time it takes for it to run)
The issue there is between an experienced Rust developer and an inexperienced one. For some reason, inexperienced developers have this idea that code written in an unsafe block is faster "because it's not checked" but that's not true. The checking happens at compile-time, not during runtime. Code run inside of "unsafe" is not faster, it's merely meant to do things the language would otherwise yell at you for... like creating bindings for unsafe languages like C. There should be very, very few reasons to use the unsafe block in your code unless you're interfacing with other languages.
@@Daktyl198 true. In the Rust forum one made a survey regarding who uses unsafe block for performance. It came as a shock to me that indeed few even do that for performance. But I am still rather new to Rust myself. The up coming Borrow Checker 2.0 will need even fewer unsafe blocks.
@@Daktyl198 well technically unsafe blocks do allow you to bypass some runtime checks, for example, bound checks on slice accesses, which normally would panic if theyre out of bounds, but instead with .get_unchecked results in undefined behaviour, reducing branching, but optimizations made possible by using unsafe blocks are usually not of this kind, it happened once in my case that the compiler couldnt prove the lifetimes of my *very expensive to clone* data, but i could.
though, it doesnt seem right to me that even inexperienced rust devs think that the actually expensive checks are done in runtime, the whole point of the language is doing a lot of compile time safety checks
"The most bike-shedding people possible, which is kernel developers"
Have you met frontend devs????? Like they spend half their time talking which specific code of conduct to adopt. That is the epitome of bike shedding, it has absolutely nothing to do with code or code performance and guess what everyone has an opinion.
Damn, three chats going at once. Insaneo style
he only looks at twitch
I think one of the things that was missed on the German strings part that nobody else mentioned is that, yes, Rust makes you write more code to achieve the same "effect". But what the Rust code does by nature of you needing to write it out, and the C code almost certainly doesn't, is that you make explicit your design and assumptions. It's not truly 100 lines of Rust vs. 20 lines of C, it's that with 70 lines of explanations in C on top.
If you don't mind, can you elaborate on the specific things a compiler can do knowing a string is in German? Thanks!
Two most toxic communities together. What can go wrong? No comment ninja vs we don’t have lib for this but your code is memory safe …
For what it's worth, around 2017/2018, Linus took a sabbatical to work on his communication style, and since then he's been much more diplomatic in his criticism! Respect where it's due, he got called out for a toxic communication style, acknowledged the issue, and then made a change!
I’m gonna assume it was more about his personal relationships
Ok the take at 6:50 is utter CRAP. Your philosophy is the method by which you contend with the human condition at the deepest level. Your philosophy should inform your religious views, your political views, and even the manner in which you relate to other human beings. Your philosophy dictates your deepest principles, it is how you ground out your beliefs. It is how you justify and understand your moral views. Equating philosophy with politics is absolutely disgusting.
Politics reaches deep into the human brain because we have entire sections of the brain dedicated to its practice, providing data to the rest of the brain all the time. When we imagine our own mind we use the parts of our brain trained on modeling other people's, with all the training it has experienced baked in.
I'd love if your take were right, but I don't think the view that philolosophy sits at the deepest level of human experience while politics doesn't is rooted in reality. Both massively shape your deepest principals, beliefs and moral views.
Considering 'who we are' is not just the mechanical logic of a brain calculating philosophy but also the mechanical process of the brain that made us social animals doing politics and the emotional processes of an animal exploring the world.
Putting them in the same category when examining how people interact with each other and the different ways they approach it seems fairly reasonable.
@@fastestdraw Politics may be a more used pathway/network in the brain. I would expect as much on an average, but most people don't ground out their politics to morals and ethics to philosophy. Philosophy must be the underpinning of a thoroughly investigated worldview. It may take up less brain space, it may have less contact with your conversations, and your interactions with the world. From a reasoning perspective you politics `aught` to be derived soundly from philosophical principles. However I would say this is the case for 1-200 individuals if not less. Most people pick up policies and political alignment based on intuition, or they simply identify with an entire group or party. They align with a political party because that is who their friends and the people they look up to are aligned with. I would never expect a study on the human brain over an average population to reflect what I described above.
I also role back the statement on how philosophy effects your relationships, the impact may be profound but likely because of second order effects. For example if your philosophy lead you to being an atheist while your family was very religious. This can have a major impact but again that impact isn't direct.
I would also stray from saying that dedicated portions of the brain are used for politics. I think politics would occur in the same portions of the brain as most other higher order information processing. The PFC, the ACC, and a bunch of other places too. I would expect philosophy to use those exact same regions as well, except for some differences, I think philosophy would be more abstract thinking and politics would involve more social and emotional processing. In terms of brain function maybe politics would have more Amygdala use versus more DMN use for philosophy. However that is all very tentative speculation.
@@usershilov Agree on the brain region/function, we do have parts of our brain that seem highly correlated with imagining other minds and predicting their actions, but that is highly unlikely to be the only place in the brain that is happening or the only thing that region does.
Couple with both language development and abstract thought appearing to be linked in our evolutionary history, and seperating out philosophy and politics gets even muddier, the comparison between them more apt.
Most people aren't sitting around logically reasoning out a philosophy using the building blocks scholars use to describe the world- they are seeking out things and returning to raw experience to see what works - 'is an idea true when I use it in my hands.' The same process is going on with politics.
This approach is both fundamentally collaborative, political, sits firmly in that second circle, and results in abstract reasoning derived soundly from the source of philosophical principal - experience.
I can't argue that it isn't the practice of philosophy.
It grounds out morals ethics politics and yes, philosophy, in a group basis. No man is an island, and neither is our understanding or reasoning. And most people have a deeply explored worldview that doesn't deserve dismissal or disgust because it fails to fit neatly into your world view.
If only 1-200 people have done something accessable to 8 billion on the planet presently, I am inclined to think it is a sampling error. But I'm willing to hear out why this 'aught' to still be considered, compare that to my experience, and see if it seems both true and functional.
@@fastestdraw First, I just want to clarify I meant 1 in 200 rather than 1 to 200 people.
It is rather rare that people care about epistemology or philosophy. However logically if you question someone on a political view for example abortion. They would provide backing for this perspective by some underlying philosophy. For example by some intrinsic measure all human life deserves a right to life, therefore, abortion should be illegal. Or another who is pro-choice for the first trimester might argue that the rights of small cluster of cells isn't significant rather the collection of organs required to host a conscious human experience is what is valuable and should be protected so only first trimester abortions. You could keep asking for justifications and they would inevitable stall (person doesn't have a developed philosophical world view) or they would provide philosophical justifications.
I shouldn't claim any knowledge on how many people have a deeply informed world view. In my experience which may be biased, people don't care, most of the people in my life, are accept a framework of belief from the people around them.
I think independent thinkers are rare but on relative scales, there are plenty of us. That doesn't mean that we each should create our own philosophy from scratch, that certainly isn't the case from me. However I do think more people than do should thoroughly consider philosophy. You should have an idea of weather you're a materialist or not, and have some justification for that position, same goes for atheism versus theism. You should consider some of the classical questions of philosophy, and dedicate some time to considering them on your own, try to come up with some method with contending with them, some framework by which to approach them. This is an invaluable pursuit.
I think philosophy is necessarily part of a well rounded education. Having explored that part of your worldview you can be much more sure in your positions you can be more confident in your beliefs, you avoid contradictions and cognitive dissonance.
I don't think that equating politics with philosophy is disgusting, that was a very hyperbolic statement. I just think that a reasonable person would form their opinions based on some philosophy.
I wouldn't say it is necessarily wrong to take the opposite approach; to circle back to the abortion argument maybe intuitively one side makes more sense to you. Then you investigate the the philosophical and moral implications. Based on that investigation you may find that your position has changed maybe not. Either way it is my belief that that investigation 'aught' to be done.
I don't think people who have a surface level understanding of politics/philosophy deserve dismissal either. I don't think their political opinions shouldn't be as valuable. I don't think of it as a character flaw, more they don't have the same set of values/interests as me. I care about politics, I care about being able to justify my political positions. I don't care that much about music, and I don't think my position that Post Malone is the greatest artist of all time, should be considered valid.
You mention - "seeking out things and returning to raw experience." What do you mean by that, are you saying people seek out bits and pieces of philosophy, which they apply to their daily life? In what ways might someone do that...
btw do you have discord?
There was more nuance to the discussion than a rage against Rust. The subsystem maintainer in this instance was just standing up to say, "Im seeing all these new type annotations starting to pop up everywhere in the kernel because of rust... If the rust folks think they need annotations all over the place - well, I'm going to continue my development in C, and I'm sorry to say that I really am not interested in supporting those annotations. If Rust needs the annotations, then someone from the Rust community is going to have to support those annotations."
I think you nailed in short the C devs concern.
What about the previous dozens of presentations that were interrupted? Apparently this behavior goes back 20 years. Seems a lot different than a "nuanced discussion".
I'm*
That is a valid concern and also a valid respond. The real issue is however with how the involved parties talk about their different opinions. Its fine for a c dev to want to continue to program in c, it is a different thing however if the rust team and the c team refuse to collaborate at a basic level when changes to the kernel are made. From what i can gather, the rust team is totally fine with supporting the annotations themselves but they at the very least would like to know when changes to the system are made.
I think goes further than "i want to continue to use c" when the rust team only finds out about changes to the system when the code doesnt work anymore.
@@leonardschungel2689 this is not a refusal, C dev are more experienced and know this will not work well. In the purposed solution C dev will not be able to do development without knowing rust, any C change can break rust binding. What they should do? Pair programming? One C and one Rust? And if you think they will be able to do changes separately you are kidding yourself it will be nightmare for Rust and C devs. In order for this to work well you need clear defined boundaries between C and Rust which are not part of the solution.
Love the content!
however, as you mentioned, there are difference between Anarchy and Chaos… IMO,
Anarchy in C would represents a decentralized yet organized codebase where components interact through clear interfaces without a single controlling entity. This fosters flexibility, maintainability, and collaborative development.
Chaos in C would signify a disorganized and unstructured codebase lacking clear boundaries, conventions, and documentation, leading to confusion, bugs, and maintenance challenges.
Not sure this is how Linux is management is Chaos… again, jut my opinion.
RE: Linux competitor written in Rust taking over from Linux, no. Language a program is written in has virtually no impact on popularity.
For something to overtake Linux, it needs to be better, and not just by a little, there is a threshold that is higher than "actually more for purpose", since there is a yuuuge amount of work to replace OSes, especially for early adopters that basically have to build supporting software as well.
A lot of what Linus says now-a-days doesn't make sense to me.
@@CoolestPossibleName I honestly haven't kept up with what he says so I can't really say either way.
what about all the 9028389023489023 drivers that have to be ported?
@@allowambeBOWWAMByeah imho that’s the biggest problem. and i don’t understand what are we going to gain when we replace the C with Rust?
@@pemifo260 It's a dead end. They would have to make a separate kernel with interface to C drivers that they can't keep up with
Rust’s ownership and borrowing model introduces a steep learning curve for developers, particularly those already familiar with the relatively simple but powerful memory model of C. For Linux kernel development, where maintaining simplicity and clarity is often prioritized due to the complexity of the system, the added cognitive overhead of managing Rust’s borrow checker could reduce productivity, especially for seasoned C developers.
C compilers and toolchains, like GCC and Clang, have been optimized for Linux development across a wide range of architectures, from x86 and ARM to more niche platforms. These toolchains are deeply integrated into the kernel’s build process, and they provide extensive support for the specific needs of kernel development, such as cross-compilation and architecture-specific optimizations.
Rust, on the other hand, relies heavily on the LLVM backend, which, while powerful, does not yet match the portability and maturity of GCC when it comes to the diverse hardware supported by Linux. Many embedded systems, for instance, depend on architectures that are not fully supported by Rust. This limits Rust’s suitability for Linux, which runs on an enormous variety of devices, from servers to embedded systems with unique constraints.
The reliance on LLVM also creates a dependency that might not be as flexible or future-proof as the existing C toolchain. Additionally, any new toolchain changes could introduce subtle issues or bugs that are difficult to detect in such a large, complex codebase like the Linux kernel.
Just use the same tool you have being using.
C is the perfect choice.
JS allows to write programs without fully knowing/understanding underlying tech or libraries. Just by having abstract knowledge of what you wanna to achieve and based on experience of working with other libraries/APIs.
Which is pretty cool. You need some graph library? OK, here is example of usage, so you will get it working quick.
In C, getting it to work quick would not fly.
Example is openssl API, which you really need to read every man page for every function you are using.
i2d_X509 function, it is literally has "Using a temporary variable is mandatory. A common mistake is to attempt to use a buffer directly as follows..." in docs. "A common mistake"... Instead of designing API, which would not lead to "common mistakes".
There is no drama, it's C programmers who hate commenting their code that are paranoid that Rust will replace them and there is literally no indication of this. Linus has said in Vienna recently IIRC that Rust is an experiment and that he is fully open to going back if it fails, he does not think it has failed. I agree with him.
I could say exactly the same thing about the rust junkies trying to worm their way in somewhere where they are guests and then throw a tantrum because they aren't catered to.
@@Leonhart_93”guests“ hahaha yall are the worst kind of people to work with
@@morkallearns781 Good. Who says I want to be welcoming or anything? If I want help I will ask for it.
If you gonna make another one-dimensional argument you gonna get banned.
@@Leonhart_93It's so bad that someone tries to add a systemic way to enforce rules that even kernel devs break - look at the linus note to dev trying to use error outside of where it should happen(in this video at the beginning). If it wasn't caught by Linus it would probably be another special case to be remembered...
By that logic from now on no one should complain about Rust in the kernel because Linus said that Rust is ok, therefore inviting it and asking for contributions.
I like C approach, you know and can disect on why something it doesn't work
apparently a lot of ignorant people do not to that and this seriously angers me , why should other more specific programmers have a expectation of how more ignorant people code , that is what a c vs rust is turning into
Also, Rust is fundamentally unsuited for (pure) kernel development, as the challenges you encounter are inherently unsafe. There's a lot of kernel stuff that you will not be able to do in safe rust. And that's fine, you can still have parts in C and some parts in Rust. Unfortunately, a lot of Rsut-bros completely skim over this fact and try to shove Rust in places where it doesn't belong.
Unsafe rust exists for a reason, and it's much easier to do unsafe rust than C interop, which requires unsafe rust anyways.
Whenever I hear bikeshedding, my inner eye produces the image of a dog that's shedding not its fur but rather bikes
It's so funny to me. The Rust team is focusing so much on pandering to Linux devs for features, prioritizing Linux dev's requests over the other 99% of their userbase. All while Linux devs themselves can't even decide if they want to keep using Rust or not. Please, please, please just let the LInux devs fix their own shit before pandering to them...
Huh
@@monsterhunter445the Rust compiler team is focusing on features that Rust for Linux wants rather than anything else, despite Rust for Linux not even being a sure thing.
It would be like gcc prioritizing the Linux kernel devs rather than just trying to be a good c compiler
99% of their userbase 😂 hehe
@@SussyBaka-nx4ge Exactly. On Reddit a similar comment got downvoted into the ground by people that didn't know that, with multiple aggressive replies. The Rust community is getting more and more of a cesspool the last couple of years.
Two languages at the same time will cause problems for everyone. Fork the repository and make your own changes has always been possible!
Maybe it is also old vs new. The old guys like me, learned coding with machine language that was as close as you can get with hardware. We loved it cause it gave you every freedom and it gave you power as well.
Rust is good when it comes to really writing stable code and you don‘t want to care too much about lifetime and memory management (as along as it doesn‘t come to lifetime qualifiers). But on the other hand it limits you in some way (which can be a good thing) and some things happen magically under the hood like with „drop“ - which is good, cause things get cleaned up automatically. But bad, cause it is not so obvious and you have to know about scope.
So, it is an interesting discussion. Some interesting problems might show up, when you try to rewrite the complete Linux kernel in Rust.
What takes longer... learning RUST or learning how not to make security mistakes programming in C?
"learning to not make mistakes" isn't really a thing though
@@Ytilee your mistake was not making a point, as you're absolutely wrong
I would say it takes longer for boomers to retire ♿️ Way too long...
@@RustIsWinning Linus is not a boomer buddy
@@RustIsWinning yes, you are way too long from your institution and meds. Go back, take your meds and rest.
@27:00 if they have the tooling for checks how much would it take to bundle it up and make it into a C spinoff language with those checks by default?
Holy C > anything else
Amen
shuuuut uuuuup
Dead ahh meme
@@TobiasCastillo-f7u Dead ahh creator
Every discussion is essentially free vs proprietary
linux community continuing to remind me why i never participated in the linux community
Good. The gatekeeping is working.
enjoy deepthroating dat microshaft
5:28 "perked out of your mind"
is it bad that I originally thought he was talking about percocet? may or may not have binged all of the class of 09s recently
vi vs. Emacs was minimalism vs. everything and the kitchen sink. There were people in university who would do everything inside Emacs, whereas vi users edited code in vi, and used the O/S and commandline for everything else.
“You need 100 lines of Rust to replace 4 lines of C” - sure, but those 100 lines encode all the edge-cases you need to think about like who owns the data, how long it lives for, how it has to be handled etc while in C you get none of that and you have to pray whoever wrote that code has written a 100 line comment above the structure definition
Would you rather read 100 lines of rust of 100 lines or comments?
Examples plz
@@sbdnsngdsnsns31312I would 1000% rather trust a compiler versus trusting every random dork that touches the kernel
Show evidence of this or I am not buying it.
All the edge cases that don't normally exist but you created them so you can solve them.
I think the heart of the comment about Linux vs Unix wasn't FOSS vs Closed Source, it was more that if enough people think that it is too difficult to get the features or fixes they want for Linux through the bureaucracy of Linux, they will go and move to somewhere else where they can get those features. Whether that is true or not, remains to be seen, the friction to create a new OS kernel is obviously pretty huge, so there would need to be a lot of discontent. That being said, as Prime pointed out, with Docker and so on, its probably a lot easier to get traction now than when people had to literally install your software on a machine.
Rust is the job security language.
Perl is the job security language 😏
It really isn't. C/C++ means you always have work everywhere in the world. If you want to make a lot of money you should learn some of the obscure languages that are still used for very specific things, like Erlang.
@@_Safety_Third_nah COBOL