@Psychx_ There are things you can't do in safe rust even though they are memory safe. Some of those things are necessary for the kernel to function, so you will have to write unsafe rust code even if it was completely rust based
I don't like the pauses for one word commentary. It is jarring and breaks focus from the video and isn't necessary. Just let the video play and then say something afterwards if you need to.
The idea isn't that the commentary guy actually provides anything of value, its just so that he can claim 'plausible' deniability for copyright infringement reasons
it's intensely irritating.. He should have titled the video "Savvynik reacts! WHOAAA Rust in the kernel, what does it implies!!!!!!!" so i would have known to click another video ^^' 1 minute in, i'm out.
No it's not. Rust has to pass a lot of waves, and I don't think it will make it in the end. C is a monster. And as always new people underestimate the power of old, tested and consistent. Furthermore I doubt that people who like C and used it for years are going to leave it for Rust
The original recording is over on Linux Foundation's channel. Dirk regularky does this Q&A style session with Linus, just search for Hohndel and Torvalds.
Recently there had been a debate on the linux kernel mailing list on a proposal how to deal with integer overflows in Linux kernel code in the future. As a sidenote within that debate Theodore Ts'o, a prominent name in Linux kernel development (mostly file system development) and definitely a very experienced C developer was complaining he got compiler and UBSAN warnings (related to integer overflow and bits cutoff) on C code he judged "as obviously correct (to a human)" and was forced to make some ugly modifications to silence the warnings. Got a reply from Linus Torvalds telling him a) the "obviously correct code" wasn't correct b) his fix to silence the warning wasn't correct either and c) how to fix the issue painlessly using some macros in the kernel available for decades. So, if a guy like Theodore Ts'o gets it wrong sometimes - who on earth is a perfect C developer then who never does one of those bugs Rust catches at compile time? Such a perfect C developer is a unicorn. Of course, all comment sections on Rust topics on the Internet are full of them. Note that writing correct C code is a considerable cognitive burden, with C being such a primitive language. Essentially you need to stick to rules very similar to those Rust is enforcing on you all the time, but have nothing but some mediocre static code analysing tools that may catch some of the occasions where you unintentionally broke those rules. It is like walking a mine field. It requires god-like discipline and awareness for every line of code written. Everyone claiming he or she does not do those bugs Rust catches, is kidding him- or herself. Compilers being helpful in catching bugs are such a relief and we all should embrace the new option to write code as efficient as C code but with the help of Rust to ensure it is correct. I was there when they introduced ANSI C which gave us function prototypes, eliminating a complete class of bugs: passing parameters to functions with the wrong types or wrong number of parameters or in the wrong order. It was so helpful. That fixed a lot of existing K&R C code at that time.
And what exactly does Rust about interger overflow? Besides obviously panicking at runtime, wich by the way, is exactly what ubsan does. Fine, Rust having it integrated into the language is nice, however you people pretend that Rust solves every problem and that simple languages like C are comparatively super-mega hard. Its not that way, whats hard is programming, if you can't solve an interger overflow bug you can't solve it in C and you can't solve it in Rust, simple as. One language might be slightly more convenient than the other (And this is a good thing for Rust of course) but thats it.
If you are scared about memory management you should not be in the linux kernel development. Where the fuck is all this coming from? Both memory and multithreading is total differnt in the kernel then in user code (libraries and apps).
@@llothar68 Your rough language makes people think you tried too much to get recognition from a stranger? Where is your rudeness came from? My view is Linus is thinking the future of Linux without Linus, aka a tractable way to keep Linux going without a/several specific masterminds. NO RESPONSE PLEASE.
Bear in mind that much of Rust's memory management is done in the standard library, for userland programs, and, just as kernel C can't use libc, kernel Rust needs to implement its own replacements for many memory management constructs which normally exist as standard library types. (eg. Box, Rc, Arc, Vec, etc.)
@@ssokolow AFAIK, Rust code is (for now) only meant for kernel drivers, not for the kernel itself. the drivers, may come from different sources, such as vendors or 3rd party contributors. This helps keep Linux fresh but also gives challenge to QC.
@@tildarusso AFAIK, you're correct on both points. Drivers only for now, and drivers are the place that needs QC assistance the most because you have a lot of different drivers, each tied to a piece of hardware that is required for testing which not everybody will have.
Senior developers are worried of losing their prestige if the primary language shifts to one they aren't masters at, even if it is better suited. It's nice to see Linus throw support at it.
*No. "This is working just fine, so don't mess with it" SHOULD be the protocol. NOT some f'ing BS about a trendy lang simply because linus has gray hair now. That is a "captain of a proverbial ship got bored and strayed from protocol at the risk of the crew" sort of situation sadly.*
Zig is not production-ready. It is an alpha, and a very incomplete alpha at that. It also doesn't solve the memory safety issues that Rust does, so it wouldn't make sense either way.
Zig is just another better C, it is certainly much nicer than C but it is not the first or the last such language that we've seen. Rust offers something that previous systems languages did not
At work, we have a similar problem: A few years ago it was allowed to use Kotlin on an equal footing with Java. Nice idea, but ended up being a nightmare to maintain code. When we hire developers, they now must master BOTH Kotlin and Java at expert level since you will encounter both syntaxes. For those who were already employed and did not know Kotlin, they were effectively downgraded to being "B programmers" and are not able to maintain large parts of the code base. We have super qualified Java developers that refuse to touch Kotlin code and we risk losing them and some has already left. You never know where Kotlin code has been mixed in and you constantly run the risk that a developer will come in who insists on using Kotlin and thus destroys the maintainability for the others. Allowing Kotlin is, in my view, the worst decision the company ever made.
I don't believe that's a valid comparison. Kotlin is IMO not the kind of improvement over Java that Rust is over C. Rust's memory safety, ensured mainly through checks at compile time, is worth a lot more than Kotlin's mainly syntactic sugar and only a few more profound language improvements - some of which you get in Java too, at least partially, with the addition of new JSRs, newer Java versions and tools like lombok. On top of that, the extensive tooling available for Java further reduces the appeal of Kotlin - Java may lack features that Kotlin has, but powerful tooling, like smart autocompletion, might make the lack of some features less costly. There's a reason Kotlin grows slower than Rust, I believe. Google started switching from C++ to Rust a while back. What they published on the topic paints an extremely favorable picture for Rust. Most programmers got production grade comfortable with Rust within 2-3 months. Experienced programmers, from both Java and C++ teams, got there even faster, within 2-3 weeks. Rust effectively doubled the productivity of C++ programmers, and proved to be highly readable, allowing for significantly faster code reviews - something I believe would be highly beneficial for the kernel too. From what you're telling, that's not at all what programmers experience with Kotlin.
I've been able to build kernels without a BPF compiler, and thus ignored it. (Any feature requiring BPF is broken by unavailable build prerequisites.) I stayed on the last GPLv2 release of several projects until I found replacements. Rust strikes me as a combination of the two: stay on the last version I can build without rust until I can migrate to a different ecosystem. (I have never had a go, swift, zig, or oberon developer tell me I'm a bad person for not using their attempt du jour to replace C, but every rust developer I've interacted with has opened with that.)
And then they get mad at us when we call it a religion. It feels like Java in the late 90's with lies like "compile once and run everywhere" and selling the idea that strict OO was the best approach to every conceivable problem. I think Rust will be the same. It will do a lot of damage before people put it back into the limited niche it belongs or just forget it.
@@nobiado484 Rust is no more a religion than C or C++. You sound like those Assembly programmers who were adamantly arguing that C was too high level and that they want to stick with Assembly until the day they die.
@@mmstick You're the one who used the word "religion", not me. Thanks for proving my point that no rust advocate has ever talked about benefits of rust (other than "we have ASAN too!"), but has instead attacked C, like I said you would. The streak remains unbroken. I code in Python, Lua, Bash, had a job doing Perl, used to teach Java courses at the local community college, and so on. C wasn't my first language and has never been my only option. I think having a language domain crossing in ring zero is stupid. If you want to write a new kernel entirely in rust, have at. Requiring developers to know multiple languages to understand the behavior of a monolithic kernel operating in a single shared address space is just sad, and being cc'd on the repeated patch sets to wrap the C red/black tree implementation in rust bindings is exhausting. (How hard would writing a new one in rust be? But no, let's add unnecessary layers of encapsulation and data translation glue because it doesn't matter what the code does, it just matters that it's written in rust...)
@@myphone4590My response was to @nobiado484, not you. None of what you stated is relevant to me or my comment. I get it, you're afraid of learning new things and want to bury your head in the sand.
The man is a living legend. Who is gonna take on the mantle when the man passes on? I can hardly imagine that one day I tell my grand children: In those days, when Linus Torvald and Dennis Ritchie were still alive...
It will take a full team to take the reigns when Linus is no longer working on the kernel. But we all hope he stays around for the next few hundred years 🤣
Linus Torvalds and community should be very proud of what they have accomplished. I trust him. I fear him leaving the group but I think that could be fixed with a Linux Constitution that the community could follow over time. Not a living constitution but a solid set of principles that are set to be followed at all cost to keep us all safe and free.
When you have hard rules you get weird interpretations and it may lead to a culture that isn't robust enough to address new situations. Look at how the Agile manifesto was turned into SCRUM hell. Idk man.
It's already been almost 10 years since Rust released. You're late. Rust already won. Its in the kernel already. Its in your web browser. Its in your operating system. Its on your phone. Android 13 released with 1.5 million lines of Rust in its source code. 23% of all new code written for Android is in Rust. Probably higher today, as that was a metric from 2022.
@@dougjohnson4266 Most of the Fortune 500 and many smaller companies have already adopted Rust at scale. Some of them are rewriting, but many more are building better software to replace their legacy systems. Discord and Dropbox rewrote their infrastructure in Rust, and were able to scale better as a result thereof. Apple, Microsoft, and Google have been rewriting portions of their products in Rust to fix security vulnerabilities. Chrome and Firefox have been getting gradually rewritten over time. The Linux Foundation is even sponsoring development of Servo, which will eventually replace Electron and possibly Firefox's Gecko engine. Virtually every website on the Internet is now being hosted through software written in Rust. If you use AWS or Cloudflare web hosting, your website is already being served by proxies written in Rust. If you use AWS or Cloudflare web workers, you're interacting with services written in Rust. Cloudflare even recently open sourced Pingora. No, I don't see a need to convince companies. Companies are already convinced and moving on this path by their own volition.
@@dougjohnson4266 Is this enough for you? → "At Google, we have decades of experience addressing, at scale, large classes of vulnerabilities that were once similarly prevalent as memory safety issues. Based on this experience we expect that high assurance memory safety can only be achieved via a Secure-by-Design approach centered around comprehensive adoption of languages with rigorous memory safety guarantees. We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety. As a consequence, we are considering a gradual transition of C++ code at Google towards other languages that are memory safe."
Linux has provided interfaces/entry points into kernel like eBPF, eBPF maps, sched-ext. Which can be used by user space languages as well. That was his intention from the start. Writing drivers is not same as writing kernel code. With these entry points languages like Zig, Odin, V can be used as well
Anyone who adheres to good coding practices can write safe code in C. The problem is that too many developers really don't have the knowledge, skills, abilities, discipline, and intelligence to write high quality code. There would be a significant improvement in code quality and a reduction in the cost of software development if the incompetent programmers were pushed out into less demanding jobs they are better suited for.
@@joemcaverage8169 An experienced programmer pays attention to detail and would catch such problems during unit testing before submitting code for integration into the application. If thorough unit testing is not being performed, then the developer is not an experienced programmer.
@@Александр-ф9в4ю If companies could hire more qualified software developers, then they would do so. The vast majority of software developers are grossly incompetent.
I agree to a certain extent, stuff like the borrow checker and RAII seems straight up stupid to me and only there so that bad programmers can more easily deal with the overengineered messes they produce. However, a stronger type system, sum types, optional types, proper array and string types, bounds checking and imterger overflow checking by default, etc. all this things are actually useful for all types of developers.
It's worth learning Rust before C, C++, or Assembly. It is harder to learn Rust if you've already picked up bad habits from C or C++. It is easier to write highly disciplined C/C++ if you've already learned Rust. Assembly is much easier to work with in Rust because it has a standardized assembly syntax that works on every OS.
@@mmstick I agree, it may sound like you should study C C++ before Rust, as it shows you low level concepts like managing memory and pointers, but in reality, Rust's abstractions are really good, to the point where you don't even need to know underlying things but can still write optimize software
I disagree w/ the above, only because if you don't understand memory management it makes it a lot harder to understand the borrow checker... and the borrow checker is the only thing that keeps rust memory safe.
LOL you trade your life on this planet learning difficult languages while your manager who used to be the popular guy in high school became your manager and asking you for updates every single day xD
As a user Rust is awesome. I just install cargo and then I have instant access to the latest in Rust software with all of the crates you can install with a simple cargo install (package) command. It does the rest of the complicated checking for dependencies! Rust works well, and haters gonna hate.
And that's exactly what i do not like in Rust. If you check in code from everywhere, then you can easily check in malware. I would prefer if there were more control and trustworthy sources with a multiple-eyes principle. Just like it is with developer libraries on Linux distributions.
@@OpenGL4everNo one is forcing you to "check in code from everywhere". If you want to build your own ecosystem TempleOS style without any reliance on open source software, then you're free to do so.
@@OpenGL4ever Not to mention that everything gets statically compiled, so after you got rid of the malicious crate, you will have to remember to recompile every binary that directly or indirectly depended on the malware.
@4ever I only install crates created by developers I trust. It's the same thing with Windows software. Practical tip: don't install software from untrusted sources. If you trust the sources, however, do as you please.
Personally, I do things the rust code will be implemented into the Linux kernel. However, I also believe that the core fundamentals of the Linux foundation have changed from their original intention. The gnu Network has drifted apart from the Foss Network on disagreements from what really is and is not free. I would like to support open source projects but I'm now forced to settle with mainstream Linux as newer technologies further bridge the gap between free and usable.
Well, I think I'm seeing more of it over time, so yeah I guess it may go to the top soon. But also... cobol certainly isn't the best and look at how far it got...
@@antifa_communist according to what metrics? how many of those people actually have deep experience with more than 5 systems programming languages? it's fine for its domain but it's not "the best"
@@conundrum2u I think they're referring to the StackOverflow Developer Survey when they call it "number 1 most loved". It's been at the top of of the "most desired programming language" chart for something like eight years running. Also, when you take into account network effects (i.e. How many people use this? We're aging and need to attract new developers.), Rust does gain a substantial lead over other languages in its "capable of both enforcing memory-safety invariants and writing low-level code" niche.
It is amazing to hear that Linus is on board with Rust. This year is going to be one of the more exciting years, I think. I can't wait for the Pop Os 24.04 release with the new Cosmic DE. Thanks for bringing us up to speed Sir.
Not really amazing, he just understands that the kids that are getting into kernel development now are bad. He doesn’t want to deal with their memory mistakes.
😂 as if the old guard had made less mistakes. It was just more likely they fixed their own bad stuff because less people cared and far less code was beeing written.
What is a value of this video? You put Linus' video on your channel and then you say same things what Linus said! Is it your way to show you're smarter then everybody else on RUclips because you think people can't get it from the first time? 🤮 Don't repost others content! Better make an original one! BTW, the interview was interesting and cool, but you'd better go and see a full version of it elsewhere!
Rust is an interesting language, however what I don't like is there is no standardization committee to handle the design changes to the language itself, as is for the C. The high agility and invention is a risk for the backwards compatibility for safety-critical applications.
I always say that talking about the memory safety is under-selling Rust. What makes Rust so special is how it provides a powerful type system without also needing a garbage collector and how that lets you teach the compiler to reliably enforce the invariants and restrictions that matter for your project. Memory safety without garbage collection is just one of the things that can be encoded in said type system. I'd also point to how its combination of language-level tagged unions (A.K.A. data-bearing enums), a lack of first-class exceptions, and having these properties from v1.0 has led to a standard library, ecosystem, and language culture that avoid hidden control flow paths.
@MorTobXDWhy it’s so hard to comprehend some people want simple, precise tool to do the job and nothing more. Like a hammer. I don’t need AI assistant for a hammer.
@@pfili9306They do not like to think for themself. Like all stupid things, it tends to kill itself off, in a way or the other, unless someone has a use in that behaviour.
Rust is just much much more complex as a language, like C++. Personally I am pretty optimistic about Zig though, the language features aren’t nearly as complex but it still has some of the benefits of these new languages, might be a good C replacement in the long run.
@@PhilfreezeCH I find c far harder to code with as the things I get explicitly annotated and documented and the compiler enforces, I have to keep in my head in c.
it's great to see Rust is competing to get into Linux rather than into Windows or Mac. Linux will be free and more awesome than the other two that charge money and treat their users like sh*t
I am not programmer (but I am interested in 'systems' in general), so take it with pinch of salt, but I think Rust may kill Linux. Memory guarantees are thrown out of the window, when using C ABI, so the only good thing that Rust brings is ability to tame Linuxes growing complexity at expense of compile time and infrastructure complexity (which itself might be problematic). Rust is good choice for a fresh start (like Redox OS), but for Linux imho Zig or something similar would be better choice. This is just bystander's observation.
Memory guarantees are not thrown out the window when importing a C library. Rust's static code analysis techniques cannot be applied to the C library that you import, but it is still being applied to all of the Rust code that you write. In fact, when working on Rust bindings for a C library, Rust provides a lot of great types for making C libraries safe to work with. So I don't understand what your hangup is, or why you'd recommend Zig which has no memory safety guarantees at all. And besides, there's more to Rust than memory safety. It has async/await, trait-based generics, pattern matching, algebraic data types, channels, options, results, iterators, thread-safety via Send and Sync type markers, ownership-based state machines, cargo, cargo doc, and the crates repository.
@mmstick well, I what I meant was that passing objects/variables to C cancels Rust's ability to track ownership etc. I do not advocate Zig in particular, I am not language preacher ;), but it seems to me it is more similar to C and would be easier to integrate in Linux ecosystem (yes, I know it is younger and less mature than Rust, but already shockingly good and seems better suited for being C replacement. To me Rust seems to be more like C++ replacement). I admire what Rust can deliver to whole software ecosystem in general, I just worry that it's shortcomings might be dangerous for Linux. I want Linux to thrive. If Rust will help - that's great, I am keeping my fingers crossed that everything will go well.
@@DJRYGAR1The Rust compiler does not need to track what a C library is doing. I don't understand where you got the idea that this even matters in relation to Rust. It only needs to track values that are returned by the C library. For example, if a C function returns a file descriptor, then you can simply wrap that into an OwnedFd newtype to get the compiler to enforce ownership semantics onto it. If a C function returns a type that has a deconstructor, then you can wrap that into a custom newtype and use that deconstructor in your Drop trait implementation. This newtype can also enforce ownership semantics and borrow checking. For someone not proclaiming to be a preacher or a programmer, you seem to be eager to preach about Zig. Zig is in a very early and incomplete alpha stage. Zig does not solve any of the memory safety issues that Rust does. It's just as easy to violate memory safety in Zig as it is in C. Speaking as someone who has experience with C, and has also written the zig slotmap library based on the slotmap library in Rust, I would heavily disagree that Zig is similar to C. There is hardly any similarity at all. Zig also does not track memory managed by C. It is impossible for any language to track how a C library manages its own memory. It doesn't even track its own memory. It will never have a borrow checker. And therefore will never be useful in the real world. It is very dangerous to promote Zig over Rust. If you want to talk about shortcomings, you needn't look any further than the fact that Rust enforces aliasing XOR mutability, and Zig does not.
@k "For someone not proclaiming to be a preacher or a programmer, you seem to be eager to preach about Zig." I literally never wrote a single line od Zig code, really (my personal interest is in higher levels/gui stuff). My questions/doubts come rather because I like Linux and I do not want to see it go down in flames ;> I have heard Rust preachers and I know generally what are good sides of it, but I also heard complains, and this is where my doubts come from. Thanks for answers anyway.
@@DJRYGAR1What made you think Rust will cause Linux to "go down in flames"? Linux was already in flames from the earliest of days because of the fires caused by Python's duck typing; and C/C++'s complete and total lack of memory safety. 70% of security vulnerabilities are caused by use of memory unsafe languages, which will also include Zig. Those vulnerabilities also cause random application behaviors, corruption, and crashes. This is why the kernel and its drivers have always been very unstable. All it takes is a single unstable driver to induce a kernel panic. Kernel panics are less common today than they were in 2010, but they're still very common. This is also why btrfs has an infamous reputation for data corruption. This is why KDE developed a reputation for being unstable and crashing constantly in the 2010s. It is why GNOME has been removing a lot of features over time to reduce the burden of maintenance. It's also why GNOME Shell's frontend is written in JavaScript. The rise of static code analysis in the 2010s happened because of how severe this issue was. Not just for kernels and applications, but web browsers too. Yet there is only so much that you can do when C/C++ lack the necessary syntax for a complete analysis. It is from this desire to fix these issues that Mozilla created Rust. The language syntax is designed around static code analysis, with its static type system and borrow checker. Aliasing XOR mutability is enforced at compile-time. Borrowing and ownership are core language level concepts. It is also for that reason that the FBI, CIA, NIST, and even the White House are now urging the industry to stop using C/C++, and focus on rewriting critical infrastructure in memory safe languages.
@@SianaGearz My bad. Forgot that Linus is a hardcore C programmer arguing that's how computers think and whatnot. Anyhow, do you think that by extension it will include C as well?
Just because there is a new technology available out there, it does not mean it's useful in specific areas. You have a new idea, good, where is it applicable, where is it useful? It is not useful?! What do you want to make with it then...
it's a mindshare issue. I'm sure there's probably some usefulness to Rust, but there's a disturbing trend for newer developers to try to replace everything with the new hotness, and that's very costly. C has 46 years of maturity behind it and Rust has a long way to go
Seriously, why not Zig? Zig is C for the future. If someone is not disciplined enough for manual memory safety, then that person just should not do kernel programming or low level programming at all. I mean no one in the right mind would trust the programming of a space probe or a lander to a Java jockey, right?
thats funny cuz people did try to code critical goverment code in java back when that was hot&new. also in rust you can do manual memory managment. language itself allows you to easaly insert assembly into your code. that means it can do anything any other system programing language can and can get as low as phisicaly possible to the cpu. Also memory managment in rust being done automaticaly is nothing *but* good when working within a large codebase and being confident all memory is droped when variable goes out of scope.
@@MarteenHobbu Rust is only nice, when when it can be used in safe mode. However unsafe rust is way worse then C (look up "When Zig is safer and faster than Rust" at zackoverflow) So if an application requires design patterns that are only implementable in unsafe Rust, then writing that in Rust is excruciating. On the other hand, Zig is designed around working with unsafe design patterns. It has a lot of debug and test facilities which makes working with memory-unsafe things relatively easy. In addition it allows for way more fine grained control than C (e.g memory allocators). In that regard it is "lower level" than C. So cutting edge performance can be achieved with it, especially compared to unsafe Rust. Also Zig's, memory safety features allows for better interoperability with legacy C code. So until the issues of unsafe Rust are not addressed, Rust will be at a disadvantage against Zig, in these state-of-the-art applications.
@@MarteenHobbu Rust is only nice, when when it can be used in safe mode. However unsafe rust is way worse then C (look up "When Zig is safer and faster than Rust" at zackoverflow) So if an application requires design patterns that are only implementable in unsafe Rust, then writing that in Rust is excruciating. On the other hand, Zig is designed around working with unsafe design patterns. It has a lot of debug and test facilities which makes working with memory-unsafe things relatively easy. In addition it allows for way more fine grained control than C (e.g memory allocators). In that regard it is "lower level" than C. So cutting edge performance can be achieved with it, especially compared to unsafe Rust. Also Zig's, memory safety features allows for better interoperability with legacy C code. So until the issues of unsafe Rust are not addressed, Rust will be at a disadvantage against Zig, in these state-of-the-art applications.
@@MarteenHobbu Rust is only nice, when when it can be used in safe mode. However unsafe rust is way worse then C. (look up "When Zig is safer and faster than Rust" at zackoverflow) So if an application requires design patterns that are only implementable in unsafe Rust, then writing that in Rust is excruciating. On the other hand, Zig is designed around working with unsafe design patterns. It has a lot of debug and test facilities which makes working with memory-unsafe things relatively easy. In addition it allows for way more fine grained control than C (e.g memory allocators). In that regard it is "lower level" than C. So cutting edge performance can be achieved with it, especially compared to unsafe Rust. Also Zig's, memory safety features allows for better interoperability with legacy C code. So until the issues of unsafe Rust are not addressed, Rust will be at a disadvantage against Zig, in these state-of-the-art applications.
@@rafaelrosa3841 Redox OS is an officially registered non-profit organization with a board of directors. That is not a toy. By that logic, Linux is just a hobby.
"unsafe mode" isn't some horror-show to be shunned, it's an intended part of the language which exists so you can build new constructs that the safe-mode layer can use safely but doesn't know how to automatically check the innards of. (eg. much of the Rust standard library is built using unsafe.) The point is that you design your `unsafe` code so that it prevents safe Rust from calling the C it's wrapping in invalid ways. That greatly reduces how thoroughly you need to audit your code to reach X amount of quality.
LOL you trade your life on this planet learning difficult languages while your manager who used to be the popular guy in high school became your manager and asking you for updates every single day xD
@@vytah Wrong, NASA does it everyday. C code is on Mars. I have also worked for companies that manufactures radars for jets, they also use C. The difference is that they are skilled and know how to use the power that C gives. There are differences between computer scientist and simple developers. *Avoid generic developers, not C.*
@@User-uk6rk and now look at their development speed and costs, and also on how they restrict the programming environment. It's basically about using C as a faster BASIC, with all the limitations, but without any guarantees, which they then have to supply manually on their own. Even NASA developers would not be able to write safe C at a normal development pace when given a task that cannot be architected to fit into the "safe C" limits.
I haven't tried rust extensively just yet. But I think it's a good thing from what I've read. I don't see it replacing something like C any time soon. I also don't think anyone should start with rust. They should learn C/asm first to understand what rust brings so the pros and cons can get weighed when determining what the best solution to a problem. I see rust playing more of a complimentary role over the near future.
I wouldn't recommend learning C or Assembly first. That's a surefire way to not only kill any motivation to learn how to program, but they will have zero guidance on how to manage memory properly. The Rust compiler is a very effective teacher that catches mistakes and gives very elaborate compiler messages instructing why the mistake is an issue and how to fix it.
@@mmstickLearning Rust without knowing C seems like a strange choice. Many design choices in Rust are based on common problems with C. I think something simple like Python or C# could be a decent choice for beginners.
@@QazCetelic It's hardly a strange choice. I learned before C and was much better prepared to properly handle memory in C afterwards, using the same idioms and practices as I used in Rust. Simulating move semantics with pointer stealing, and adhering to aliasing XOR mutability principles. If you start with C, you won't have the foresight to adhere to memory safe practices.
stability and longevity are critical when considering new high level languages for an operating system kernel. C was mature by the time Linus decided to write the first kernel and it's only gotten more refined as time has gone on. Rust and Zig have yet to prove themselves to be more than fads. If either lasts 15 years before another newer language is "the bestest ever!" then maybe they should be considered. what I don't want to see happening is anything like the javascript community where there's everyone writing new hotness every year and you're left to catch up and evaluate whether any of it is worthwhile. that's extremely counterproductive.
@@conundrum2u Rust has been stable for 9 years. That is not young by any standard. It has also already seen widespread adoption in every industry, so the industry doesn't agree with you. The web browser you're using contains Rust code. The Linux kernel already has drivers and subsystems written in Rust. Many firmware developers have been writing firmware and realtime operating systems with Rust for many years now. Windows, Mac OS, and Android already use Rust internally. 23% of all code written for Android were Rust in 2022. Android 13 released with 1.5 million lines of Rust.
@@mmstick stable is not mature. just because people put it in something does not validate its usage. no one is gatekeeping binaries because of the language it's written in, it's the commitment by the majority of the community that matters. C was more mature than Rust is when Linus started writing the linux kernel. I think you're confusing lines of code with validity. You can have all of the fools writing code in a particular programming language but it doesn't mean it should be validated just because there are all of those fools writing in that language. It has to prove itself that it has true long term staying power, and I just don't see it yet. I'm sure you would like for it to be considered mature and all that, but it isn't yet. If anything there's less reason to migrate from C over to Rust because there's over 46 years of knowledge behind C.
I tried using rust to port one of my C projects, where you would draw a circle beneath your cursor on the screen, the circle radius is runtime chosen but cant be below 1 or above 50, the screen size was 360x180, and the rust compiler compiled the code with no warnings, but when the executable is ran it panics when drawing a circle near a screen edge, this is really simple to detect, and if rust couldn't detect these things, both known at compile time, I can only imagine how useless it actually is for kernel development. The compiler could have at least said "Circle may try to draw out of bounds if radius is bigger then "
I don't know how it is a language problem that you might be doing a bad implementation or using a library incorrectly. I'm sure the panic told you exactly what you did wrong.
This has nothing to do with Rust and everything to do with the library you are using, and the misuse of its API. In most cases, it is ideal if libraries return errors instead of panicking, but its up the library author to decide whether a condition is severe enough to warrant panicking on a bad input. Panics include stack traces which the user should report to the developer to tell them what assertion their code failed. Panics do not violate memory safety. They are used to indicate that a programming mistake has been made and should be fixed in the source code. You must have submitted values which were out of bounds, and therefore the library responded by telling you that your code has mistakenly supplied out of bounds values. If you want to avoid panics at runtime, make sure to write code that does not panic. Use newtypes and state machines to validate inputs, and return errors when inputs fail.
Microsoft heavily invests in a lot of things, then a few years down the line drops them like a hot bag of dog shit. it's called diversification and it's a sound business strategy, but most of those projects are huge wastes of money. just because they've thrown entire departments at a technology doesn't mean it's going anywhere. don't mind me I'm going to go play with my Kinect API
This will never work because Linus is statically linked and there are 0 binary Linux distros you would have to rewrite the entire kernel in Rust. Every package in Linux has to be compiled with GCC
The NAME is enough to keep me from bothering to learn it. I did install it a few Fedora versions ago and it hosed everything. I'll stay with python and "C".
@@dkkogmaw1311 What? Do you try to tell me, that C isn't optimizing and generates the same output every time? And neither CPP, nor Rust support reviewing the generated assemblies? And: do you _need_ to know? Then why are you using a compiler at all, instead of coding directly in Assembler? This is thoroughly messed up.
@@dkkogmaw1311even Linus was bitten several times by gcc when the output was NOT what he'd guess from the C code. So no, predicting compiler output is not easy, even in C
@@krillin6How so? Does it have a central authority, like a god, Apple, or Microsoft? Is it a world view or ideology that surrounds itself around mythology, spiritualism, have rituals or a doctrine prescribing or even controlling of how one has to live their life, especially their sex life? Is being a tool for Microsoft, Google, Apple... despite their mind control and usury not much closer to a religion, and you a gullible blind faith believer? Try this: If you don't want to be exposed a fool, then keep your mouth shut, and no one will know.
Rust is hideous. It is one of the most ugly languages I've seen yet. Kind of like Java and C++ tried to have a child and failed. The absolute worst of both. Massive vulnerability material. Unreadable crap. That's how I feel....
@@richardclark7679 The authors of Rust have more Programming Language Theorists among them than I've ever seen in any other language to break out into the mainstream... there's just a big gap between what language families have been popular in business and what language families have been popular in academia. Hence that whole "Ocaml pretending to be C++ to be more appealing" thing. Rust looks alien because ML isn't descended from C. That's it. You want to see what PLT people get up to when they're NOT trying to court mainstream success? Try writing a little Haskell. (Or, if you want to see the last time an academic language not descended from C achieved mainstream success, try writing some Pascal. In the early days of the Macintosh, it held the role C holds in UNIX/Linux, and Borland Turbo Pascal was the Visual Basic or C# of DOS, as far as market share went.) EDIT: ...oh yeah. RUclips doesn't actually track which comment I was replying to... only who, so I didn't need to reply twice.
@@ssokolowKeyword "theorists". Theory and reality differ greatly at times. This is one of them. WYSIWYG and KISS rule supreme. Always will. There is nothing in academia than can compare to real life. That's the problem. And no, Rust looks alien because it is. It does not adhere to WYSIWYG or the infamous KISS principle. Clean, simple, easy to read, easy to follow code is the answer to security problems. Complexity always fails.
@@richardclark7679 You REALLY don't want me to start pointing out how much C does NOT get to call itself WYSIWYG or KISS just because it punts so much as 'implementation-defined' in so many subtle ways. This is, at best, an "English vs. Japanese. Neither one is objectively 'more intuitive'." sort of situation. (And English is C, because their history has left both of them with objectively more internal inconsistencies lurking to trip over.)
The hope is that it's even harder to introduce bugs than it is to write, so maybe (fingers crossed) things can be slightly less bug-ridden. It's hard to write entirely correct code in C too, you mostly get almost correct code.
i wouldn't say that rust is messy. i would agree that rust is indeed difficult but i find C to be even more difficult. I love low level stuff for sure, but i don't think it's worth it to keep all of that in mind just to deal with common stuff that languages like rust, zig and go made easy to deal with.
I don't understand the appeal of Rust tbh. C is ubiquitous, and timeless. Freeing memory just isn't that difficult to justify yet another language of the week.
The problem is that there's a LOT of empirical evidence that, no matter how well skilled individuals can write correct C or C++, people in groups cannot. Rust was designed to be the software equivalent to a lockout-tagout system. It protects you from changes you didn't see others making and vice-versa.
@@SnakeEngine Ahh, the "you need better coders" fallacy. Companies like Microsoft tried that and couldn't shake that ~70% memory-safety bugs percentage. Stuff is bigger, more complex, more ambitious, and more Internet-connected than it was back then. Beyond a certain size, humans working in groups just can't write correct code, no matter how skilled they are individually. It's like flawed parallel architectures. You wind up choosing between data corruption and your project thrashing on your synchronization primitives.
So the Linux kernel is getting all rusted and I wonder how long before it all falls apart. If it is backed by Microsoft avoid. Typescript is one example of how a simple language like Javascript is being mangled with types. C and Javascript are meant to be simple languages and that remains their strengths. If you wanted types that you will use Java or C++ and not force a language to be something that it is not. Simplicity is strength and let C, Javascript and Perl be as they are ...
Do you need more vitamins and proteins ... maybe. How about more ... and some more and then even more so...... well .. and the before long the reasoning falls apart and you begin to see the truth. Type safety and memory safety maybe good to a point and beyond it, it makes little sense. Typescript is a very good example of how the type safety idea is oversold to mangle javascript. All the reasons mentioned as disadvantages for c, perl, javascript etc ... are actually seen as advantages and the reasons why these languages are powerful, SIMPLICITY. These and many other languages grew organically in popularity backed by love from the community and which is why even if these are deemed as imperfect and problematic by large corporations, those are actually the very same reasons why anything may be popular in the first place. If c c++ java javascript any may other ideas are bad then let us remember why the idea of Linux happened in first place. If we had listened to Microsoft then Linux was a bad idea and should not have had any reason to exist because Microsoft OS was so good. The community thankfully disagreed and the world has a very imperfect Linux now. We need c perl javascript java and c++ even more than before. Hopefully Typescript and rust disappear are atleast become irrelevant with time. Typescript is simply a horrendous idea, backed by Microsoft @@visheshnowbut6841
There is no reason to talk about advantages and disadvantages of introducing Rust into the Linux kernel, if we all know doing that is a political decision. Somebody up there has no balls to create an OS from scratch with his arbitrary technical decisions, so he forces these changes upon existing successful projects. It would be really enough to fork the source code and do your own stuff there. Forcing Linus to be a face of "progress" is shameful.
@@spicynoodle7419 Nothing of that is really relevant for any more serious project - where around 80-90% of time are spent on other things than writing code. And it comes nowhere near the memory safety of Rust. And - as any developer who worked on bigger projects can tell you - that's what is really relevant. It's all about giving guarantees and there is just no other alternative to Rust - which allows you to write very high level code with low-level optimizations AND gives your strong memory guarantees. And thinking that the borrow check is BS is just a skill issue and being lazy - lazy to properly design your code in a way that respects these rules. They are there for a reason.
It’s jarring hearing the old C guys who have learned nothing but C over the last 40 years refute Rust not based on merit but just because learning it would inconvenience them. I’ve learned nearly 20 languages over my career and I see the merits of Rust and how it’s benefitted from over 40 years of mistakes of C, such as the NULL reference, and innovated such things as borrow checking and requiring unsafe blocks be specifically declared as unsafe. It’s like people who drive gas guzzlers complaining about hybrid/electric vehicles when these would help solve both energy prices and the planet. People who want to go back to the 70’s: maybe it’s time to retire? Hopefully Linus is trying to win these people over with diplomacy but these naysayers in the kernel group are dividing rather than uniting people.
for me rust seems like total nonsense because I am used to reading and writing languages based on c formatting. Rust seems to have all kinds of weird things happening everywhere.
For me, the Internet is total nonsense because I am used to reading and writing letters based on hand writing. The Internet seems to have all kinds of weird things happening everywhere.
If it makes it make a bit more sense, Rust's syntax is basically Ocaml wrapped in some C++ syntax to make it less alien. For example, the 'a syntax used for explicit lifetimes is Ocaml's generic syntax, equvialent to C++'s , because, on a theoretical level, lifetimes are a special kind of generic/template parameter. (Though I will agree that it looks ugly and confusing for its use of an unpaired single quote.) Rust is more or less a GC-less ML derivative and the ML lineage is only a year younger than C (1972 vs. 1973), by the sources Wikipedia chose and the Rust compiler was originally written in Ocaml.
Zig is in alpha, the Linux kernel needs something more stable. You can't rewrite the kernel because the programming language itself changed in some fundamental way. There might come a time where Zig is in the kernel, but that time is not today, nor should it be.
@@LaughingOrange I didn't say "Zig NOW!!!" like some leftwing activist. I said "Zig," as in, "Don't waste time with Rust, which is hard to learn, disliked by many who've tried it, and is less performant than C++." If the argument for using a different language is simply to use new technology and avoid stagnancy, Zig will likely be finished, is faster than C/C++/Rust, and has a growing, enthusiastic base behind it who understand CS.
I do see Zig and Rust working together in the future when Zig hits stable. Zig looks like you can incrementally improve C where unsafe is needed while Rust safe needs a rewrite.
Recent studies are showing that use of AI-assisted coding is leading to a significant increase in mistakes. So much so that it is causing a loss in productivity compared to not using it at all.
@irivanov7342 Everything that an AI does is a predictive hallucination. There already exists software for machine translation to convert C to Rust, which AI needn't apply.
@@JayDee-b5u Good question. I presume since Rust can ensure borrow semantics at compile time, then it can presumably emit more efficient code. There was some nvme driver written in Rust, that was more performant than C one.
@@RustIsWinning first wait for rust devs to be born. After they need to identify their gender, which they shall probably call "young not binary chimp". Then let this chimp grow. Because airplanes need to fly and cars need to move and machines to work. No other choices than C++ and C yet.
Do you think Rust is going to become a significant part of the Linux kernel?
@IanMurdocksimmortalsoulhaha neden turkce yorum yaptin ki?
Yes. At some point in the distant future, the C-code will be rewritten in Rust in order to guarantee memory safety for the whole kernel.
@@Psychx_ the day when everyone with 2 fingers worth of forehead will finally move to BSD.
@@tiranito2834Too late for you. BSDs are already adopting Rust.
@Psychx_ There are things you can't do in safe rust even though they are memory safe. Some of those things are necessary for the kernel to function, so you will have to write unsafe rust code even if it was completely rust based
I don't like the pauses for one word commentary. It is jarring and breaks focus from the video and isn't necessary. Just let the video play and then say something afterwards if you need to.
yes quite horrible and adds nothing. commentary should elaborate and make the viewer smarter... or keep quiet
It's.like.putting.a.period.on.each.word
it sure got my down vote..
The idea isn't that the commentary guy actually provides anything of value, its just so that he can claim 'plausible' deniability for copyright infringement reasons
it's intensely irritating.. He should have titled the video "Savvynik reacts! WHOAAA Rust in the kernel, what does it implies!!!!!!!" so i would have known to click another video ^^' 1 minute in, i'm out.
Background comments are the worst. Please don’t do that
totally agree
the kernel's getting rusty
Haha
ironically and not ironically
Will probably oxidize till nothing is left if we let rust touch C
I FElt that
No it's not. Rust has to pass a lot of waves, and I don't think it will make it in the end. C is a monster. And as always new people underestimate the power of old, tested and consistent. Furthermore I doubt that people who like C and used it for years are going to leave it for Rust
Stop interrupting the damn video.
Is there a version without comments and cuts?
Come on, there were only like 2-3 cuts. Does it bother you so much?
The original recording is over on Linux Foundation's channel.
Dirk regularky does this Q&A style session with Linus, just search for Hohndel and Torvalds.
@@grenadier4702 yes
Recently there had been a debate on the linux kernel mailing list on a proposal how to deal with integer overflows in Linux kernel code in the future. As a sidenote within that debate Theodore Ts'o, a prominent name in Linux kernel development (mostly file system development) and definitely a very experienced C developer was complaining he got compiler and UBSAN warnings (related to integer overflow and bits cutoff) on C code he judged "as obviously correct (to a human)" and was forced to make some ugly modifications to silence the warnings. Got a reply from Linus Torvalds telling him a) the "obviously correct code" wasn't correct b) his fix to silence the warning wasn't correct either and c) how to fix the issue painlessly using some macros in the kernel available for decades.
So, if a guy like Theodore Ts'o gets it wrong sometimes - who on earth is a perfect C developer then who never does one of those bugs Rust catches at compile time? Such a perfect C developer is a unicorn. Of course, all comment sections on Rust topics on the Internet are full of them.
Note that writing correct C code is a considerable cognitive burden, with C being such a primitive language. Essentially you need to stick to rules very similar to those Rust is enforcing on you all the time, but have nothing but some mediocre static code analysing tools that may catch some of the occasions where you unintentionally broke those rules. It is like walking a mine field. It requires god-like discipline and awareness for every line of code written. Everyone claiming he or she does not do those bugs Rust catches, is kidding him- or herself.
Compilers being helpful in catching bugs are such a relief and we all should embrace the new option to write code as efficient as C code but with the help of Rust to ensure it is correct. I was there when they introduced ANSI C which gave us function prototypes, eliminating a complete class of bugs: passing parameters to functions with the wrong types or wrong number of parameters or in the wrong order. It was so helpful. That fixed a lot of existing K&R C code at that time.
And what exactly does Rust about interger overflow? Besides obviously panicking at runtime, wich by the way, is exactly what ubsan does.
Fine, Rust having it integrated into the language is nice, however you people pretend that Rust solves every problem and that simple languages like C are comparatively super-mega hard. Its not that way, whats hard is programming, if you can't solve an interger overflow bug you can't solve it in C and you can't solve it in Rust, simple as. One language might be slightly more convenient than the other (And this is a good thing for Rust of course) but thats it.
At least RUST promises decent memory management, critical for Linux kernel. A good match in theory therefore worth trying.
If you are scared about memory management you should not be in the linux kernel development. Where the fuck is all this coming from? Both memory and multithreading is total differnt in the kernel then in user code (libraries and apps).
@@llothar68 Your rough language makes people think you tried too much to get recognition from a stranger? Where is your rudeness came from? My view is Linus is thinking the future of Linux without Linus, aka a tractable way to keep Linux going without a/several specific masterminds. NO RESPONSE PLEASE.
Bear in mind that much of Rust's memory management is done in the standard library, for userland programs, and, just as kernel C can't use libc, kernel Rust needs to implement its own replacements for many memory management constructs which normally exist as standard library types. (eg. Box, Rc, Arc, Vec, etc.)
@@ssokolow AFAIK, Rust code is (for now) only meant for kernel drivers, not for the kernel itself. the drivers, may come from different sources, such as vendors or 3rd party contributors. This helps keep Linux fresh but also gives challenge to QC.
@@tildarusso AFAIK, you're correct on both points. Drivers only for now, and drivers are the place that needs QC assistance the most because you have a lot of different drivers, each tied to a piece of hardware that is required for testing which not everybody will have.
Senior developers are worried of losing their prestige if the primary language shifts to one they aren't masters at, even if it is better suited. It's nice to see Linus throw support at it.
*No. "This is working just fine, so don't mess with it" SHOULD be the protocol. NOT some f'ing BS about a trendy lang simply because linus has gray hair now. That is a "captain of a proverbial ship got bored and strayed from protocol at the risk of the crew" sort of situation sadly.*
Somehow still feel like zig would have made much more sense in kernal..
Because of the cult of done
Zig is not production-ready. It is an alpha, and a very incomplete alpha at that. It also doesn't solve the memory safety issues that Rust does, so it wouldn't make sense either way.
Zig may be fine as a better c, but what rust gives is guaranteed compile-time resource management safety. I like not being allowed to make mistakes.
but it is still very early, and its tooling has not yet matured
Zig is just another better C, it is certainly much nicer than C but it is not the first or the last such language that we've seen. Rust offers something that previous systems languages did not
At work, we have a similar problem: A few years ago it was allowed to use Kotlin on an equal footing with Java. Nice idea, but ended up being a nightmare to maintain code. When we hire developers, they now must master BOTH Kotlin and Java at expert level since you will encounter both syntaxes. For those who were already employed and did not know Kotlin, they were effectively downgraded to being "B programmers" and are not able to maintain large parts of the code base. We have super qualified Java developers that refuse to touch Kotlin code and we risk losing them and some has already left. You never know where Kotlin code has been mixed in and you constantly run the risk that a developer will come in who insists on using Kotlin and thus destroys the maintainability for the others. Allowing Kotlin is, in my view, the worst decision the company ever made.
I don't believe that's a valid comparison. Kotlin is IMO not the kind of improvement over Java that Rust is over C. Rust's memory safety, ensured mainly through checks at compile time, is worth a lot more than Kotlin's mainly syntactic sugar and only a few more profound language improvements - some of which you get in Java too, at least partially, with the addition of new JSRs, newer Java versions and tools like lombok. On top of that, the extensive tooling available for Java further reduces the appeal of Kotlin - Java may lack features that Kotlin has, but powerful tooling, like smart autocompletion, might make the lack of some features less costly. There's a reason Kotlin grows slower than Rust, I believe.
Google started switching from C++ to Rust a while back. What they published on the topic paints an extremely favorable picture for Rust. Most programmers got production grade comfortable with Rust within 2-3 months. Experienced programmers, from both Java and C++ teams, got there even faster, within 2-3 weeks. Rust effectively doubled the productivity of C++ programmers, and proved to be highly readable, allowing for significantly faster code reviews - something I believe would be highly beneficial for the kernel too. From what you're telling, that's not at all what programmers experience with Kotlin.
I've been able to build kernels without a BPF compiler, and thus ignored it. (Any feature requiring BPF is broken by unavailable build prerequisites.)
I stayed on the last GPLv2 release of several projects until I found replacements.
Rust strikes me as a combination of the two: stay on the last version I can build without rust until I can migrate to a different ecosystem.
(I have never had a go, swift, zig, or oberon developer tell me I'm a bad person for not using their attempt du jour to replace C, but every rust developer I've interacted with has opened with that.)
And then they get mad at us when we call it a religion. It feels like Java in the late 90's with lies like "compile once and run everywhere" and selling the idea that strict OO was the best approach to every conceivable problem. I think Rust will be the same. It will do a lot of damage before people put it back into the limited niche it belongs or just forget it.
@@nobiado484 Rust is no more a religion than C or C++. You sound like those Assembly programmers who were adamantly arguing that C was too high level and that they want to stick with Assembly until the day they die.
@@mmstick Next kernel will be 100% Java. :)
@@mmstick You're the one who used the word "religion", not me.
Thanks for proving my point that no rust advocate has ever talked about benefits of rust (other than "we have ASAN too!"), but has instead attacked C, like I said you would. The streak remains unbroken.
I code in Python, Lua, Bash, had a job doing Perl, used to teach Java courses at the local community college, and so on. C wasn't my first language and has never been my only option.
I think having a language domain crossing in ring zero is stupid. If you want to write a new kernel entirely in rust, have at. Requiring developers to know multiple languages to understand the behavior of a monolithic kernel operating in a single shared address space is just sad, and being cc'd on the repeated patch sets to wrap the C red/black tree implementation in rust bindings is exhausting. (How hard would writing a new one in rust be? But no, let's add unnecessary layers of encapsulation and data translation glue because it doesn't matter what the code does, it just matters that it's written in rust...)
@@myphone4590My response was to @nobiado484, not you. None of what you stated is relevant to me or my comment. I get it, you're afraid of learning new things and want to bury your head in the sand.
The man is a living legend. Who is gonna take on the mantle when the man passes on? I can hardly imagine that one day I tell my grand children: In those days, when Linus Torvald and Dennis Ritchie were still alive...
It will take a full team to take the reigns when Linus is no longer working on the kernel.
But we all hope he stays around for the next few hundred years 🤣
@@kahnfatman if he passes away nothing important shall change, if he wasn't born nothing significant would change either.
Linus Torvalds and community should be very proud of what they have accomplished. I trust him. I fear him leaving the group but I think that could be fixed with a Linux Constitution that the community could follow over time. Not a living constitution but a solid set of principles that are set to be followed at all cost to keep us all safe and free.
Yea and stop the amendments at 13.
When you have hard rules you get weird interpretations and it may lead to a culture that isn't robust enough to address new situations. Look at how the Agile manifesto was turned into SCRUM hell. Idk man.
@@ոakedsquirtle Valid Point
compile times for linux will increase 10x once they choose to integrate rust into the kernel at the rate the compiler speed is at.
Shouldn't include code written in a language by programmers who can't write a compiler.
Having written a linux module in rust it does not use nor should it use any crates than standard. Still much slower than compiling c but not to bad.
It will only matter if you modify the rust code, otherwise will be marginal.
First it was Java, then .NET, then ???. Now it is Rust that is going to take over. Ask this question in 10 years.
It's already been almost 10 years since Rust released. You're late. Rust already won. Its in the kernel already. Its in your web browser. Its in your operating system. Its on your phone. Android 13 released with 1.5 million lines of Rust in its source code. 23% of all new code written for Android is in Rust. Probably higher today, as that was a metric from 2022.
@mmstick That is great, but try and convince thousands of companies to rewrite/replace millions of lines of working code for no reason. ($)
@@dougjohnson4266 Most of the Fortune 500 and many smaller companies have already adopted Rust at scale. Some of them are rewriting, but many more are building better software to replace their legacy systems.
Discord and Dropbox rewrote their infrastructure in Rust, and were able to scale better as a result thereof. Apple, Microsoft, and Google have been rewriting portions of their products in Rust to fix security vulnerabilities. Chrome and Firefox have been getting gradually rewritten over time. The Linux Foundation is even sponsoring development of Servo, which will eventually replace Electron and possibly Firefox's Gecko engine.
Virtually every website on the Internet is now being hosted through software written in Rust. If you use AWS or Cloudflare web hosting, your website is already being served by proxies written in Rust. If you use AWS or Cloudflare web workers, you're interacting with services written in Rust. Cloudflare even recently open sourced Pingora.
No, I don't see a need to convince companies. Companies are already convinced and moving on this path by their own volition.
@@dougjohnson4266 Is this enough for you? → "At Google, we have decades of experience addressing, at scale, large classes of vulnerabilities that were once similarly prevalent as memory safety issues. Based on this experience we expect that high assurance memory safety can only be achieved via a Secure-by-Design approach centered around comprehensive adoption of languages with rigorous memory safety guarantees. We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety. As a consequence, we are considering a gradual transition of C++ code at Google towards other languages that are memory safe."
@@dougjohnson4266they will, Rust will start with big companies. Smaller companies will fellow
Linux has provided interfaces/entry points into kernel like eBPF, eBPF maps, sched-ext. Which can be used by user space languages as well.
That was his intention from the start.
Writing drivers is not same as writing kernel code.
With these entry points languages like Zig, Odin, V can be used as well
v's a scam
@@rw_panic0_0 I do not believe that
Anyone who adheres to good coding practices can write safe code in C. The problem is that too many developers really don't have the knowledge, skills, abilities, discipline, and intelligence to write high quality code. There would be a significant improvement in code quality and a reduction in the cost of software development if the incompetent programmers were pushed out into less demanding jobs they are better suited for.
Lack of proper string and array types is big problem for experienced programmers too. It's too easy to make mistakes.
@@joemcaverage8169 An experienced programmer pays attention to detail and would catch such problems during unit testing before submitting code for integration into the application. If thorough unit testing is not being performed, then the developer is not an experienced programmer.
🤣 just hire better developers
@@Александр-ф9в4ю If companies could hire more qualified software developers, then they would do so. The vast majority of software developers are grossly incompetent.
I agree to a certain extent, stuff like the borrow checker and RAII seems straight up stupid to me and only there so that bad programmers can more easily deal with the overengineered messes they produce.
However, a stronger type system, sum types, optional types, proper array and string types, bounds checking and imterger overflow checking by default, etc. all this things are actually useful for all types of developers.
is being rusty in Rust good?
Yes!
It seems it's worth learning Rust programming language after C, C++ and Assembly Language
It's worth learning Rust before C, C++, or Assembly. It is harder to learn Rust if you've already picked up bad habits from C or C++. It is easier to write highly disciplined C/C++ if you've already learned Rust. Assembly is much easier to work with in Rust because it has a standardized assembly syntax that works on every OS.
@@mmstick I agree, it may sound like you should study C C++ before Rust, as it shows you low level concepts like managing memory and pointers, but in reality, Rust's abstractions are really good, to the point where you don't even need to know underlying things but can still write optimize software
I disagree w/ the above, only because if you don't understand memory management it makes it a lot harder to understand the borrow checker... and the borrow checker is the only thing that keeps rust memory safe.
LOL you trade your life on this planet learning difficult languages while your manager who used to be the popular guy in high school became your manager and asking you for updates every single day xD
@@mmstick I learned C then Rust.
I didn't dive into C++ a lot yet.
But pretty comfortable with Rust after I learned C.
As a user Rust is awesome. I just install cargo and then I have instant access to the latest in Rust software with all of the crates you can install with a simple cargo install (package) command. It does the rest of the complicated checking for dependencies! Rust works well, and haters gonna hate.
And that's exactly what i do not like in Rust. If you check in code from everywhere, then you can easily check in malware. I would prefer if there were more control and trustworthy sources with a multiple-eyes principle. Just like it is with developer libraries on Linux distributions.
@@OpenGL4everNo one is forcing you to "check in code from everywhere". If you want to build your own ecosystem TempleOS style without any reliance on open source software, then you're free to do so.
@@mmstick That wasn't my point.
@@OpenGL4ever Not to mention that everything gets statically compiled, so after you got rid of the malicious crate, you will have to remember to recompile every binary that directly or indirectly depended on the malware.
@4ever I only install crates created by developers I trust. It's the same thing with Windows software. Practical tip: don't install software from untrusted sources. If you trust the sources, however, do as you please.
I think he would love Zig, it's the better fit for the kernel imho
Personally, I do things the rust code will be implemented into the Linux kernel. However, I also believe that the core fundamentals of the Linux foundation have changed from their original intention. The gnu Network has drifted apart from the Foss Network on disagreements from what really is and is not free. I would like to support open source projects but I'm now forced to settle with mainstream Linux as newer technologies further bridge the gap between free and usable.
I'm so tired of people pumping rust. If it's good, it will rise to the top.
And it is. It's the number 1 most loved language
Well, I think I'm seeing more of it over time, so yeah I guess it may go to the top soon. But also... cobol certainly isn't the best and look at how far it got...
@@antifa_communist according to what metrics? how many of those people actually have deep experience with more than 5 systems programming languages? it's fine for its domain but it's not "the best"
@@conundrum2u I think they're referring to the StackOverflow Developer Survey when they call it "number 1 most loved". It's been at the top of of the "most desired programming language" chart for something like eight years running. Also, when you take into account network effects (i.e. How many people use this? We're aging and need to attract new developers.), Rust does gain a substantial lead over other languages in its "capable of both enforcing memory-safety invariants and writing low-level code" niche.
This "pumping" is literally the language raising to the top
Interesting!
It is amazing to hear that Linus is on board with Rust. This year is going to be one of the more exciting years, I think. I can't wait for the Pop Os 24.04 release with the new Cosmic DE. Thanks for bringing us up to speed Sir.
Not really amazing, he just understands that the kids that are getting into kernel development now are bad. He doesn’t want to deal with their memory mistakes.
😂 as if the old guard had made less mistakes. It was just more likely they fixed their own bad stuff because less people cared and far less code was beeing written.
What is a value of this video? You put Linus' video on your channel and then you say same things what Linus said! Is it your way to show you're smarter then everybody else on RUclips because you think people can't get it from the first time? 🤮
Don't repost others content! Better make an original one!
BTW, the interview was interesting and cool, but you'd better go and see a full version of it elsewhere!
he also added his annoying and cringey off-screen comments to it. So it's even worse than in was in original.
Rust is an interesting language, however what I don't like is there is no standardization committee to handle the design changes to the language itself, as is for the C. The high agility and invention is a risk for the backwards compatibility for safety-critical applications.
Rust Foundation is standardization committee
Good idea-lets use a memory safe language to write code whose main objective is to manage memory.
I always say that talking about the memory safety is under-selling Rust. What makes Rust so special is how it provides a powerful type system without also needing a garbage collector and how that lets you teach the compiler to reliably enforce the invariants and restrictions that matter for your project. Memory safety without garbage collection is just one of the things that can be encoded in said type system. I'd also point to how its combination of language-level tagged unions (A.K.A. data-bearing enums), a lack of first-class exceptions, and having these properties from v1.0 has led to a standard library, ecosystem, and language culture that avoid hidden control flow paths.
@@ssokolow you speak so much give me your github page i want to see your rust code :D just post here your git page : D
@@ssokolow Low level code doesn't need type safety. It's vastly overrated.
@@SnakeEngine I'm glad the people whose opinions actually matter seem to disagree with you.
@@ssokolow Whatever, that doesn't make them right.
The Rust is getting kernely #RedoxOS
We can appreciate how open minded Linus is here having in mind his history
I'm against AI call me old school, but i dont think UNIX type systems need it.. give me a shell and im happy... AI pfff
@MorTobXDI am I do not like AI
@MorTobXDWhy it’s so hard to comprehend some people want simple, precise tool to do the job and nothing more. Like a hammer. I don’t need AI assistant for a hammer.
@@pfili9306bro please accept your smart toothbrush it will allow us to DDoS everyone in the world plz
@@pfili9306They do not like to think for themself. Like all stupid things, it tends to kill itself off, in a way or the other, unless someone has a use in that behaviour.
I can't imagine starting a project in c when I could start it in rust.
30% of bugs cannot be caught by the Rust compiler...good luck with the learning curve. I'm not in the field but just dabble in it
Rust is just much much more complex as a language, like C++.
Personally I am pretty optimistic about Zig though, the language features aren’t nearly as complex but it still has some of the benefits of these new languages, might be a good C replacement in the long run.
@@PhilfreezeCH I find c far harder to code with as the things I get explicitly annotated and documented and the compiler enforces, I have to keep in my head in c.
@@raylopez99 Learning curve? Lol. I was productive in Rust in about a few weeks only - and so will any decent programmer.
@@PhilfreezeCH You seem to be pretty clueless about C++ and Rust - I've been working with C++ for over two decades. It's way more complex than Rust.
it's great to see Rust is competing to get into Linux rather than into Windows or Mac. Linux will be free and more awesome than the other two that charge money and treat their users like sh*t
I wish I could be smarter like many people in this comment section! Really I do!
I am not programmer (but I am interested in 'systems' in general), so take it with pinch of salt, but I think Rust may kill Linux. Memory guarantees are thrown out of the window, when using C ABI, so the only good thing that Rust brings is ability to tame Linuxes growing complexity at expense of compile time and infrastructure complexity (which itself might be problematic). Rust is good choice for a fresh start (like Redox OS), but for Linux imho Zig or something similar would be better choice. This is just bystander's observation.
Memory guarantees are not thrown out the window when importing a C library. Rust's static code analysis techniques cannot be applied to the C library that you import, but it is still being applied to all of the Rust code that you write. In fact, when working on Rust bindings for a C library, Rust provides a lot of great types for making C libraries safe to work with. So I don't understand what your hangup is, or why you'd recommend Zig which has no memory safety guarantees at all. And besides, there's more to Rust than memory safety. It has async/await, trait-based generics, pattern matching, algebraic data types, channels, options, results, iterators, thread-safety via Send and Sync type markers, ownership-based state machines, cargo, cargo doc, and the crates repository.
@mmstick well, I what I meant was that passing objects/variables to C cancels Rust's ability to track ownership etc. I do not advocate Zig in particular, I am not language preacher ;), but it seems to me it is more similar to C and would be easier to integrate in Linux ecosystem (yes, I know it is younger and less mature than Rust, but already shockingly good and seems better suited for being C replacement. To me Rust seems to be more like C++ replacement).
I admire what Rust can deliver to whole software ecosystem in general, I just worry that it's shortcomings might be dangerous for Linux. I want Linux to thrive. If Rust will help - that's great, I am keeping my fingers crossed that everything will go well.
@@DJRYGAR1The Rust compiler does not need to track what a C library is doing. I don't understand where you got the idea that this even matters in relation to Rust. It only needs to track values that are returned by the C library.
For example, if a C function returns a file descriptor, then you can simply wrap that into an OwnedFd newtype to get the compiler to enforce ownership semantics onto it.
If a C function returns a type that has a deconstructor, then you can wrap that into a custom newtype and use that deconstructor in your Drop trait implementation. This newtype can also enforce ownership semantics and borrow checking.
For someone not proclaiming to be a preacher or a programmer, you seem to be eager to preach about Zig. Zig is in a very early and incomplete alpha stage. Zig does not solve any of the memory safety issues that Rust does. It's just as easy to violate memory safety in Zig as it is in C.
Speaking as someone who has experience with C, and has also written the zig slotmap library based on the slotmap library in Rust, I would heavily disagree that Zig is similar to C. There is hardly any similarity at all.
Zig also does not track memory managed by C. It is impossible for any language to track how a C library manages its own memory. It doesn't even track its own memory. It will never have a borrow checker. And therefore will never be useful in the real world.
It is very dangerous to promote Zig over Rust. If you want to talk about shortcomings, you needn't look any further than the fact that Rust enforces aliasing XOR mutability, and Zig does not.
@k "For someone not proclaiming to be a preacher or a programmer, you seem to be eager to preach about Zig."
I literally never wrote a single line od Zig code, really (my personal interest is in higher levels/gui stuff). My questions/doubts come rather because I like Linux and I do not want to see it go down in flames ;> I have heard Rust preachers and I know generally what are good sides of it, but I also heard complains, and this is where my doubts come from. Thanks for answers anyway.
@@DJRYGAR1What made you think Rust will cause Linux to "go down in flames"? Linux was already in flames from the earliest of days because of the fires caused by Python's duck typing; and C/C++'s complete and total lack of memory safety.
70% of security vulnerabilities are caused by use of memory unsafe languages, which will also include Zig. Those vulnerabilities also cause random application behaviors, corruption, and crashes.
This is why the kernel and its drivers have always been very unstable. All it takes is a single unstable driver to induce a kernel panic. Kernel panics are less common today than they were in 2010, but they're still very common. This is also why btrfs has an infamous reputation for data corruption.
This is why KDE developed a reputation for being unstable and crashing constantly in the 2010s. It is why GNOME has been removing a lot of features over time to reduce the burden of maintenance. It's also why GNOME Shell's frontend is written in JavaScript.
The rise of static code analysis in the 2010s happened because of how severe this issue was. Not just for kernels and applications, but web browsers too. Yet there is only so much that you can do when C/C++ lack the necessary syntax for a complete analysis.
It is from this desire to fix these issues that Mozilla created Rust. The language syntax is designed around static code analysis, with its static type system and borrow checker. Aliasing XOR mutability is enforced at compile-time. Borrowing and ownership are core language level concepts.
It is also for that reason that the FBI, CIA, NIST, and even the White House are now urging the industry to stop using C/C++, and focus on rewriting critical infrastructure in memory safe languages.
If the Rust Foundation managed to get it to interop with C++, I think its incorporation would be closer than Linus thinks.
Why? There is no C++ ecosystem in the kernel! Linus has always objected to C++.
@@SianaGearz My bad. Forgot that Linus is a hardcore C programmer arguing that's how computers think and whatnot. Anyhow, do you think that by extension it will include C as well?
@@mindfulnessrock pardon?
A hardcore C programmer that is open to work with Rust in oppose to C++. 😝 @@mindfulnessrock
@@mindfulnessrock C for lyfe. you take your OOP elsewhere ;D
Just because there is a new technology available out there, it does not mean it's useful in specific areas. You have a new idea, good, where is it applicable, where is it useful? It is not useful?! What do you want to make with it then...
Are you talking about Rust as not being useful? Memory safety would be awesome for the linux kernel!
Do you need mental health support? Like are you trying to be daft? The fact that people like you could be writing code scares me.
it's a mindshare issue. I'm sure there's probably some usefulness to Rust, but there's a disturbing trend for newer developers to try to replace everything with the new hotness, and that's very costly. C has 46 years of maturity behind it and Rust has a long way to go
@@conundrum2u everything needs to be 46 years old to be mature?
@@conundrum2u Rust isn't "new hotness" - It's been around for almost a decade.
Seriously, why not Zig? Zig is C for the future.
If someone is not disciplined enough for manual memory safety, then that person just should not do kernel programming or low level programming at all.
I mean no one in the right mind would trust the programming of a space probe or a lander to a Java jockey, right?
thats funny cuz people did try to code critical goverment code in java back when that was hot&new.
also in rust you can do manual memory managment. language itself allows you to easaly insert assembly into your code. that means it can do anything any other system programing language can and can get as low as phisicaly possible to the cpu.
Also memory managment in rust being done automaticaly is nothing *but* good when working within a large codebase and being confident all memory is droped when variable goes out of scope.
@@MarteenHobbu Rust is only nice, when when it can be used in safe mode. However unsafe rust is way worse then C (look up "When Zig is safer and faster than Rust" at zackoverflow)
So if an application requires design patterns that are only implementable in unsafe Rust, then writing that in Rust is excruciating.
On the other hand, Zig is designed around working with unsafe design patterns.
It has a lot of debug and test facilities which makes working with memory-unsafe things relatively easy.
In addition it allows for way more fine grained control than C (e.g memory allocators). In that regard it is "lower level" than C. So cutting edge performance can be achieved with it, especially compared to unsafe Rust.
Also Zig's, memory safety features allows for better interoperability with legacy C code.
So until the issues of unsafe Rust are not addressed, Rust will be at a disadvantage against Zig, in these state-of-the-art applications.
@@MarteenHobbu Rust is only nice, when when it can be used in safe mode. However unsafe rust is way worse then C (look up "When Zig is safer and faster than Rust" at zackoverflow)
So if an application requires design patterns that are only implementable in unsafe Rust, then writing that in Rust is excruciating.
On the other hand, Zig is designed around working with unsafe design patterns.
It has a lot of debug and test facilities which makes working with memory-unsafe things relatively easy.
In addition it allows for way more fine grained control than C (e.g memory allocators). In that regard it is "lower level" than C. So cutting edge performance can be achieved with it, especially compared to unsafe Rust.
Also Zig's, memory safety features allows for better interoperability with legacy C code.
So until the issues of unsafe Rust are not addressed, Rust will be at a disadvantage against Zig, in these state-of-the-art applications.
@@MarteenHobbu Rust is only nice, when when it can be used in safe mode. However unsafe rust is way worse then C. (look up "When Zig is safer and faster than Rust" at zackoverflow)
So if an application requires design patterns that are only implementable in unsafe Rust, then writing that in Rust is excruciating.
On the other hand, Zig is designed around working with unsafe design patterns.
It has a lot of debug and test facilities which makes working with memory-unsafe things relatively easy.
In addition it allows for way more fine grained control than C (e.g memory allocators). In that regard it is "lower level" than C. So cutting edge performance can be achieved with it, especially compared to unsafe Rust.
Also Zig's, memory safety features allows for better interoperability with legacy C code.
So until the issues of unsafe Rust are not addressed, Rust will be at a disadvantage against Zig, in these state-of-the-art applications.
@@MarteenHobbu Automatic memory management is really slow when used the way you described, this is especially true for large projects.
Rust is not for kernels. Try and make a library, or better yet! Interface with a c lib (has to be done in unsafe mode).
Try explaining that to Redox OS.
@@mmstick redox is a toy OS, there is a lot out there, even in C# and java.
@@rafaelrosa3841 Redox OS is an officially registered non-profit organization with a board of directors. That is not a toy. By that logic, Linux is just a hobby.
"unsafe mode" isn't some horror-show to be shunned, it's an intended part of the language which exists so you can build new constructs that the safe-mode layer can use safely but doesn't know how to automatically check the innards of. (eg. much of the Rust standard library is built using unsafe.)
The point is that you design your `unsafe` code so that it prevents safe Rust from calling the C it's wrapping in invalid ways. That greatly reduces how thoroughly you need to audit your code to reach X amount of quality.
And? That's how it is intended to be. Safe-Rust gives you memory safety guarantees, C doesn't - so it has to be marked unsafe.
Rust is making IBM power machines rust with SIGILL and 1 year bug still open. Irony isn't lost on me
LOL you trade your life on this planet learning difficult languages while your manager who used to be the popular guy in high school became your manager and asking you for updates every single day xD
If you feel useless, remember the guy who comments Linus in this video
Instead of avioding C, get better C developers.
*Why sacrifice performance efficiency because of developer incompetence.*
Are the better C developers in the room with us right now?
This has literally never worked. There are literally no C developers that can write safer code than an average Rust developer.
@@vytah Wrong, NASA does it everyday. C code is on Mars. I have also worked for companies that manufactures radars for jets, they also use C.
The difference is that they are skilled and know how to use the power that C gives. There are differences between computer scientist and simple developers.
*Avoid generic developers, not C.*
@@User-uk6rk and now look at their development speed and costs, and also on how they restrict the programming environment. It's basically about using C as a faster BASIC, with all the limitations, but without any guarantees, which they then have to supply manually on their own. Even NASA developers would not be able to write safe C at a normal development pace when given a task that cannot be architected to fit into the "safe C" limits.
You are right in trying to not avoid something... which is why linus is trying not to avoid new things like rust...
I haven't tried rust extensively just yet. But I think it's a good thing from what I've read. I don't see it replacing something like C any time soon. I also don't think anyone should start with rust. They should learn C/asm first to understand what rust brings so the pros and cons can get weighed when determining what the best solution to a problem. I see rust playing more of a complimentary role over the near future.
I wouldn't recommend learning C or Assembly first. That's a surefire way to not only kill any motivation to learn how to program, but they will have zero guidance on how to manage memory properly. The Rust compiler is a very effective teacher that catches mistakes and gives very elaborate compiler messages instructing why the mistake is an issue and how to fix it.
@@mmstickLearning Rust without knowing C seems like a strange choice. Many design choices in Rust are based on common problems with C. I think something simple like Python or C# could be a decent choice for beginners.
@@QazCetelic It's hardly a strange choice. I learned before C and was much better prepared to properly handle memory in C afterwards, using the same idioms and practices as I used in Rust. Simulating move semantics with pointer stealing, and adhering to aliasing XOR mutability principles. If you start with C, you won't have the foresight to adhere to memory safe practices.
@@QazCetelic python is a good choice, moving into rust, thats how i got where i am writing complex distributed systems purely in rust. no C in sight
I actually like it the commentary, feels like I'm having a sports commentator. Gives more immersion, and I like the reflections!
stability and longevity are critical when considering new high level languages for an operating system kernel. C was mature by the time Linus decided to write the first kernel and it's only gotten more refined as time has gone on. Rust and Zig have yet to prove themselves to be more than fads. If either lasts 15 years before another newer language is "the bestest ever!" then maybe they should be considered. what I don't want to see happening is anything like the javascript community where there's everyone writing new hotness every year and you're left to catch up and evaluate whether any of it is worthwhile. that's extremely counterproductive.
Rust already proved itself. Zig has not, and explicitly states in its project goals that it will not compete with Rust.
@@mmstick rust is still far too young
@@conundrum2u Rust has been stable for 9 years. That is not young by any standard. It has also already seen widespread adoption in every industry, so the industry doesn't agree with you.
The web browser you're using contains Rust code. The Linux kernel already has drivers and subsystems written in Rust. Many firmware developers have been writing firmware and realtime operating systems with Rust for many years now. Windows, Mac OS, and Android already use Rust internally. 23% of all code written for Android were Rust in 2022. Android 13 released with 1.5 million lines of Rust.
@@mmstick stable is not mature. just because people put it in something does not validate its usage. no one is gatekeeping binaries because of the language it's written in, it's the commitment by the majority of the community that matters. C was more mature than Rust is when Linus started writing the linux kernel. I think you're confusing lines of code with validity. You can have all of the fools writing code in a particular programming language but it doesn't mean it should be validated just because there are all of those fools writing in that language. It has to prove itself that it has true long term staying power, and I just don't see it yet. I'm sure you would like for it to be considered mature and all that, but it isn't yet. If anything there's less reason to migrate from C over to Rust because there's over 46 years of knowledge behind C.
@@conundrum2u That's one of the dumbest arguments I've read here so far. Rust, as it is today, is more mature than C ever has been.
If so you could introduce C++ Loooooong time ago.
I tried using rust to port one of my C projects, where you would draw a circle beneath your cursor on the screen, the circle radius is runtime chosen but cant be below 1 or above 50, the screen size was 360x180, and the rust compiler compiled the code with no warnings, but when the executable is ran it panics when drawing a circle near a screen edge, this is really simple to detect, and if rust couldn't detect these things, both known at compile time, I can only imagine how useless it actually is for kernel development. The compiler could have at least said "Circle may try to draw out of bounds if radius is bigger then "
Skill issue
I don't know how it is a language problem that you might be doing a bad implementation or using a library incorrectly. I'm sure the panic told you exactly what you did wrong.
This has nothing to do with Rust and everything to do with the library you are using, and the misuse of its API. In most cases, it is ideal if libraries return errors instead of panicking, but its up the library author to decide whether a condition is severe enough to warrant panicking on a bad input. Panics include stack traces which the user should report to the developer to tell them what assertion their code failed. Panics do not violate memory safety. They are used to indicate that a programming mistake has been made and should be fixed in the source code. You must have submitted values which were out of bounds, and therefore the library responded by telling you that your code has mistakenly supplied out of bounds values. If you want to avoid panics at runtime, make sure to write code that does not panic. Use newtypes and state machines to validate inputs, and return errors when inputs fail.
You might want to consider a different hobby.
You had C code with out of bounds accesses, of course it crashes when ported to a safe language.
Here is the twist, Microsoft is heavily investing on Rust project.
Microsoft heavily invests in a lot of things, then a few years down the line drops them like a hot bag of dog shit. it's called diversification and it's a sound business strategy, but most of those projects are huge wastes of money. just because they've thrown entire departments at a technology doesn't mean it's going anywhere. don't mind me I'm going to go play with my Kinect API
As does Amazon, Google, Facebook, and everyone else. Even the Linux Foundation is sponsoring Servo.
Hardly any twist, Microsoft has been a member of the Linux Foundation since 2016.
This will never work because Linus is statically linked and there are 0 binary Linux distros you would have to rewrite the entire kernel in Rust. Every package in Linux has to be compiled with GCC
Really please leave off the pausing / commentary. We are watching to hear Linus' comments. Just stop
Totally agree!
Tux 🐧 and Ferris 🦀 are friends. 🙂
The NAME is enough to keep me from bothering to learn it. I did install it a few Fedora versions ago and it hosed everything. I'll stay with python and "C".
Your opinion is VERY VERY important forvus! 😂
Nothing better than C.
@@RustIsWinning McDonalds is winning over quality food, too.
I would prefer to see a fork of the kernel that stays in C and assembly. The kernel doesn't need Rust.
Yeah sure why would an operating system that gets patched by thousands of people benefit from automated memory safety guarantees.
@@lordsharshabeel do you know 1:1 what the compiler gonna do with your code if you write in rust it’s same with cpp meanwhile in c you know the output
@@dkkogmaw1311 What? Do you try to tell me, that C isn't optimizing and generates the same output every time? And neither CPP, nor Rust support reviewing the generated assemblies? And: do you _need_ to know? Then why are you using a compiler at all, instead of coding directly in Assembler?
This is thoroughly messed up.
@@dkkogmaw1311even Linus was bitten several times by gcc when the output was NOT what he'd guess from the C code. So no, predicting compiler output is not easy, even in C
I'd rather not see a fork. I just don't want rust in Linux.
I'm a devout Linux user for over a decade! I like penguin people!!🐧🐧🐧
More proof Linux is a religion...
@@krillin6How so? Does it have a central authority, like a god, Apple, or Microsoft? Is it a world view or ideology that surrounds itself around mythology, spiritualism, have rituals or a doctrine prescribing or even controlling of how one has to live their life, especially their sex life?
Is being a tool for Microsoft, Google, Apple... despite their mind control and usury not much closer to a religion, and you a gullible blind faith believer?
Try this: If you don't want to be exposed a fool, then keep your mouth shut, and no one will know.
Rust is hideous. It is one of the most ugly languages I've seen yet. Kind of like Java and C++ tried to have a child and failed. The absolute worst of both. Massive vulnerability material. Unreadable crap. That's how I feel....
skill issue
@@vytahQuite true. The authors of Rust had clearly never programmed before.
@@richardclark7679 The authors of Rust have more Programming Language Theorists among them than I've ever seen in any other language to break out into the mainstream... there's just a big gap between what language families have been popular in business and what language families have been popular in academia. Hence that whole "Ocaml pretending to be C++ to be more appealing" thing. Rust looks alien because ML isn't descended from C. That's it.
You want to see what PLT people get up to when they're NOT trying to court mainstream success? Try writing a little Haskell. (Or, if you want to see the last time an academic language not descended from C achieved mainstream success, try writing some Pascal. In the early days of the Macintosh, it held the role C holds in UNIX/Linux, and Borland Turbo Pascal was the Visual Basic or C# of DOS, as far as market share went.)
EDIT: ...oh yeah. RUclips doesn't actually track which comment I was replying to... only who, so I didn't need to reply twice.
@@ssokolowKeyword "theorists". Theory and reality differ greatly at times. This is one of them. WYSIWYG and KISS rule supreme. Always will. There is nothing in academia than can compare to real life. That's the problem. And no, Rust looks alien because it is. It does not adhere to WYSIWYG or the infamous KISS principle. Clean, simple, easy to read, easy to follow code is the answer to security problems. Complexity always fails.
@@richardclark7679 You REALLY don't want me to start pointing out how much C does NOT get to call itself WYSIWYG or KISS just because it punts so much as 'implementation-defined' in so many subtle ways. This is, at best, an "English vs. Japanese. Neither one is objectively 'more intuitive'." sort of situation. (And English is C, because their history has left both of them with objectively more internal inconsistencies lurking to trip over.)
Rust is a bad choice for the kernel. Zig would be more suitable once it's finalized.
Why
WD-40
Rust is not efficient for writing code, its messy and difficult language to work out
The hope is that it's even harder to introduce bugs than it is to write, so maybe (fingers crossed) things can be slightly less bug-ridden. It's hard to write entirely correct code in C too, you mostly get almost correct code.
yeah bro fully agreed, now go tell linus how to actually develop kernel
@@lobotomy-victim Linus developed kernel in C you dumbo
i wouldn't say that rust is messy. i would agree that rust is indeed difficult but i find C to be even more difficult. I love low level stuff for sure, but i don't think it's worth it to keep all of that in mind just to deal with common stuff that languages like rust, zig and go made easy to deal with.
Detected someone who has literaly no idea of programming xD
😊😊😊
I'm pretty sure I would understand his point if there were no cuts. Thanks for sharing something interesting in a completely useless form.
I don't understand the appeal of Rust tbh. C is ubiquitous, and timeless. Freeing memory just isn't that difficult to justify yet another language of the week.
If you don't understand, it's because you don't have any experience writing and maintaining software. Programming as a hobby in private doesn't count.
The problem is that there's a LOT of empirical evidence that, no matter how well skilled individuals can write correct C or C++, people in groups cannot. Rust was designed to be the software equivalent to a lockout-tagout system. It protects you from changes you didn't see others making and vice-versa.
It's the "people working in groups" part that's the problem. Rust is basically a lockout-tagout system for group coding.
@@ssokolow You just need the right people in the group, period. Complex games were made in teams in pure C back then.
@@SnakeEngine Ahh, the "you need better coders" fallacy. Companies like Microsoft tried that and couldn't shake that ~70% memory-safety bugs percentage. Stuff is bigger, more complex, more ambitious, and more Internet-connected than it was back then. Beyond a certain size, humans working in groups just can't write correct code, no matter how skilled they are individually. It's like flawed parallel architectures. You wind up choosing between data corruption and your project thrashing on your synchronization primitives.
So the Linux kernel is getting all rusted and I wonder how long before it all falls apart. If it is backed by Microsoft avoid. Typescript is one example of how a simple language like Javascript is being mangled with types. C and Javascript are meant to be simple languages and that remains their strengths. If you wanted types that you will use Java or C++ and not force a language to be something that it is not. Simplicity is strength and let C, Javascript and Perl be as they are ...
Now it’s even backed by the US government lol
rust would completely replace c and hope also java
Do you need more vitamins and proteins ... maybe. How about more ... and some more and then even more so...... well .. and the before long the reasoning falls apart and you begin to see the truth. Type safety and memory safety maybe good to a point and beyond it, it makes little sense. Typescript is a very good example of how the type safety idea is oversold to mangle javascript. All the reasons mentioned as disadvantages for c, perl, javascript etc ... are actually seen as advantages and the reasons why these languages are powerful, SIMPLICITY. These and many other languages grew organically in popularity backed by love from the community and which is why even if these are deemed as imperfect and problematic by large corporations, those are actually the very same reasons why anything may be popular in the first place. If c c++ java javascript any may other ideas are bad then let us remember why the idea of Linux happened in first place. If we had listened to Microsoft then Linux was a bad idea and should not have had any reason to exist because Microsoft OS was so good. The community thankfully disagreed and the world has a very imperfect Linux now. We need c perl javascript java and c++ even more than before. Hopefully Typescript and rust disappear are atleast become irrelevant with time. Typescript is simply a horrendous idea, backed by Microsoft @@visheshnowbut6841
@@SavvyNik Ada 3was backed up by gov yet its there and dead : D
There is no reason to talk about advantages and disadvantages of introducing Rust into the Linux kernel, if we all know doing that is a political decision.
Somebody up there has no balls to create an OS from scratch with his arbitrary technical decisions, so he forces these changes upon existing successful projects. It would be really enough to fork the source code and do your own stuff there. Forcing Linus to be a face of "progress" is shameful.
Rust being used in the kernel is purely a technical decision. Anyone speaking otherwise is paranoid delusional.
Zig would have been a better choice
Zig time will come...
Why would a language that is still in alpha be a better choice?
Because?
@@artxiom seamless integration with C. Type safety and comptime without the BS of the borrow checker. Integrated testing suite. It feels like C
@@spicynoodle7419
Nothing of that is really relevant for any more serious project - where around 80-90% of time are spent on other things than writing code.
And it comes nowhere near the memory safety of Rust. And - as any developer who worked on bigger projects can tell you - that's what is really relevant. It's all about giving guarantees and there is just no other alternative to Rust - which allows you to write very high level code with low-level optimizations AND gives your strong memory guarantees.
And thinking that the borrow check is BS is just a skill issue and being lazy - lazy to properly design your code in a way that respects these rules. They are there for a reason.
yeeeeessss lets fkingooooooooo
If it isn't C it should be zig
He’s not speaking his mind. Rust won’t be included in the kernel as long as he is alive. He’s just saying this to keep people contributing
You're saying Linus died in 2022?
Meh
Your constant interruptions are very annoying.
It’s jarring hearing the old C guys who have learned nothing but C over the last 40 years refute Rust not based on merit but just because learning it would inconvenience them. I’ve learned nearly 20 languages over my career and I see the merits of Rust and how it’s benefitted from over 40 years of mistakes of C, such as the NULL reference, and innovated such things as borrow checking and requiring unsafe blocks be specifically declared as unsafe. It’s like people who drive gas guzzlers complaining about hybrid/electric vehicles when these would help solve both energy prices and the planet. People who want to go back to the 70’s: maybe it’s time to retire? Hopefully Linus is trying to win these people over with diplomacy but these naysayers in the kernel group are dividing rather than uniting people.
Worst commentary ever
for me rust seems like total nonsense because I am used to reading and writing languages based on c formatting. Rust seems to have all kinds of weird things happening everywhere.
For me, the Internet is total nonsense because I am used to reading and writing letters based on hand writing. The Internet seems to have all kinds of weird things happening everywhere.
If it makes it make a bit more sense, Rust's syntax is basically Ocaml wrapped in some C++ syntax to make it less alien. For example, the 'a syntax used for explicit lifetimes is Ocaml's generic syntax, equvialent to C++'s , because, on a theoretical level, lifetimes are a special kind of generic/template parameter. (Though I will agree that it looks ugly and confusing for its use of an unpaired single quote.)
Rust is more or less a GC-less ML derivative and the ML lineage is only a year younger than C (1972 vs. 1973), by the sources Wikipedia chose and the Rust compiler was originally written in Ocaml.
Rust is a joke!
RIP Linux.
@@RustIsWinning Only in your trip dreams.
Zig would be much better than Rust. Sadly it came about a bit too late.
Zig
Zig is in alpha, the Linux kernel needs something more stable. You can't rewrite the kernel because the programming language itself changed in some fundamental way. There might come a time where Zig is in the kernel, but that time is not today, nor should it be.
@@LaughingOrange I didn't say "Zig NOW!!!" like some leftwing activist. I said "Zig," as in, "Don't waste time with Rust, which is hard to learn, disliked by many who've tried it, and is less performant than C++." If the argument for using a different language is simply to use new technology and avoid stagnancy, Zig will likely be finished, is faster than C/C++/Rust, and has a growing, enthusiastic base behind it who understand CS.
I do see Zig and Rust working together in the future when Zig hits stable. Zig looks like you can incrementally improve C where unsafe is needed while Rust safe needs a rewrite.
@@OldKing11100 I was interested in rust for a while and then I saw the crazy syntax. Python for RAD, and C for fast code.
No
Imaging AI rewriting the whole kernel from C to Rust, in automated way. This is the way!
Recent studies are showing that use of AI-assisted coding is leading to a significant increase in mistakes. So much so that it is causing a loss in productivity compared to not using it at all.
@k I am not talking about assisted coding, but translating, which should be more trustworthy than predictive coding.
@irivanov7342 Everything that an AI does is a predictive hallucination. There already exists software for machine translation to convert C to Rust, which AI needn't apply.
@@dragomirivanov7342 Like a compiler from c->rust? What does Rust really do that a borrow checking compiler couldn't do?
@@JayDee-b5u Good question. I presume since Rust can ensure borrow semantics at compile time, then it can presumably emit more efficient code. There was some nvme driver written in Rust, that was more performant than C one.
There is no benefit of putting Rust in the kernel.
This is boll shit. He kinda supports RUST, cause he doesn't have bolls to go against mainstream.
He isn't Bjorn.
@@RustIsWinning first wait for rust devs to be born. After they need to identify their gender, which they shall probably call "young not binary chimp". Then let this chimp grow.
Because airplanes need to fly and cars need to move and machines to work.
No other choices than C++ and C yet.
Stop interrupting the damn video.