Rust Is Going To Destroy The Linux Kernel!!!

It depends on where they used 3rd party crates like Tokio. If they did then it's a no brainer why she worked fast, there's also the fact that she's done it before.

Rust crates have an abandonware problem.

“Asaho Lina” is a man

One might ask why C was chosen as the main implementation language. The answer is really simple: 1) it was there, 2) tradition (it was developed to implement Unix).

Choosing Rust is a matter of practicality, in the end. If enough people find it practical enough, and it still fits well enough with the rest of the kernel, it will be used. I don't see a problem with that.

I use FreeBSD, not because of this, but because I like how the system works with base and 3rd party package separation.

Plus, things don’t change for the sake of change, we still use ifconfig, for example.

Oh, and there’s never a chance systemd will come over, either.

If Rust actually has some advantage, then that feature should be added to C rather than completely switching languages.

How come Rust is OK, but C++ isn't? C++ is much closer to C and also eliminates manual memory management.

C coders are the Amish of developers

I learned to code in C back in 1998. I haven't learned Rust but I know some of the basics, I have coded in multiple other languages and met lots of other developers. I have done a little in kernel development, and I know multiple systems that are very different to the standards, and In my experience "kernel developers" are myopic conservatives, sort of like amish. Do to their experience with C, they have no idea about PLT and what you can achieve with static analysis, and especially with a sound type system like the one Rust has, because they have this narrow and constraint mind of how kernels should work, they are cult members, following a specific school and tradition, and they have no experience in different types of systems.

With a type system like Rust's, the compiler proof invariants in your system, types are like a generic test suite with 100% coverage, always. This is how the compiler guides you, because it does the analysis of the code, of all the implications is going to have. Technically you can implement an external type system and static analyzer for assembly and tell the user all the consequences of your actions, and prevent you from shooting yourself in the foot.

A sound type system also allows testing mechanisms that a programming language like C can't get on its own, but is still possible to prove it, using the external type system, Haskell has something QuickCheck and you give it a type description and then from that type generates randoms sequences, and minimizes until finding the minimal sequence of data that produces a bug, and then you can fix it. The guy who made QuickCheck works for Volvo and he tests all the C code in the cars with another implementation of QuickCheck he made for another language Erlang, because Erlang has a better C FFI than Haskell because Erlang isn't lazy like Haskell, and if some process in Erlang hangs is easily restarted automatically by its own supervisor tree.

The world is going crazy, no surprise that some dumb person would come up with something like Rust.

It depends on your workflow in c wether it is harder than rust

The kernel could use emojicode for all I care, as long as it works and doesn't cause problems for me as the user.

I don't much care but as I compile my own kernel from source the day I have to install rustc to build it correctly will annoy me greatly. I don't like having a bunch of stuff installed but for the time being it doesn't really matter.

coming from an average dev who knows both C and Rust quite well. imo you should not be writing rust code for a project as important as the kernel if you aren't capable of doing the same work in C. by knowing C you are guaranteeing that you are competent with security techniques that are required for the kernel and that you are competent enough to abstract away some of these techniques to make writing code faster. if you only know rust it is possible for you to fall into some traps which may lead to security vulnerabilities. take everything I've just said with a grain of salt, just my two cents

It's a great thing that I absolutely stopped caring about the kernel development about already nearly 20 years ago. Nothing truly interesting is happening there anyway. However I think it's great they went for Rust. They should bring on all the rest of the fancy new programming languages as well. Imagine they could have gone for Java or Kotlin or even maby C++22. THAT would be something!

I agree though, remove seatbelts.

I do not yet know how to program in rust. However, I have heard many great things about it regarding its memory safety and elimination of multi-threading issues, so it would seem to me that rust is an ideal language for kernel development

I haven't played with rust, but I remember reading somewhere that the pedigree for the language has been lost. I do not know how true that is, but of it is true, that is enough cause for concern...

"She"

Rust isn't a low level language

Rust is bust. 👎

Why use Rust when Ada does everything it does and more? It's a safer, more pleasant language to work with, easy to learn and was developed for embedded software development.

Dave’s Garage has been benchmarking all these languages and rust came out orders of magnitude faster than C. That was a specific workload but the benefit was clear. If that replicates across all tasks, unlikely but possible, the performance increase could have a measurable impact on global data centre energy usage and associated cost if a full migration were to occur. I’m definitely no expert here though so I’ll sit and wait to be ripped apart.

They just showed their true colors. DON'T let RUST creep into the KERNEL!!!

Actually, it will possibly replace it (redoxos)

I am with Drew on this one.

Imagine using Rust

I hope this is a reflection of my beginner skills but I am coding an AVL Tree in Rust and it's hell, it's really difficult. I don't think people who have never coded in Rust appreciate how much harder it is to do simple things in Rust. This is my personal experience and I have an overall positive view on Rust, but anyone saying it's not challenging makes me question their experience.

It's not beginner friendly at all. The whole argument that young developers can just pick it up like that before knowing other low-level languages seems a little dubious to me.

Rust helps remove bad c and c++ programmers that always put dangling memory management in their code and out of bound function calling (and ARGV pass-by-referencing mutating)



The rust learning curve for a self teaching programmer might take about 40 hours to get good at it; that is alot of time if you already work and have a family. But if your google-foo and search engine game is good, it might take you 1 weekend. I suggest using an AI to study Rust. Rust requires a good teacher to tell you the correct way to do it from the start. The only reason I understand rust is because I knew a 5h1t load of programming languages. C++ programmers might have the worst time because about 99% of c++ is bad programming which eventually ends up as a CVE. Bad OOP C++ does not translate well to rust (with all the badly coded inheritance stuff and templates (which most C++ user improperly use)).

P.S.
Functions returns points and pass-by-references getting mutated are bad in C and C++. Most C and C++ programmer do exactly that. Rust uses the vocabulary [borrower] which is just a new generation term for [scope]. Back in the late nighties, I had a good C and C++ roommate and his father was a programmer. My school education sucked. But me and my roommate would ask his dad how to do C and C++ code like the pros were doing it:
1. Never return pointers (but if you do only return the whole instance (like with the new constructor))
2. Never mutate pass-by-references (but if you do make sure to only send it to one function and do not do nested-function calls with the pass-by-reference (which leads to never mutate|[write a new value] pass-by-references).
3. If programming in C always use structs like this: `typedef struct S { } S ;` any method of `S` should be prefixed with `S_` and turn off function name mangling.
4. Try to only destroy||delete memory from one main function in C especially.

Rust compilers do all that stuff without you having to be a 15 year programmer. Rust compilers keep a history of memory scope and if any possibility of returning or reading or writing out-of-bounds, then the compiler is supposed to ERROR OUT or WARN you and not compile it. But if you use [unsafe], the compiler will skip those scope||borrow checks. Alot of us are only making the new stuff in rust.

Some of you guys might not care, but Rust is good at public facing programs and mission critical applications. Military, governments, missles, nuclear plants, and all types of stuff have CVE because the programmers nested too many calls passing too many pointers and got lost in the scheduling and then pre-maturely destroy the variable (but there is still a callback function that is read and writing to undefined memory). I don't know if they teach that stuff anymore in uni or college, but they did when I was there.

why you made this video just switch to bsd, linux dont need guys like you who have no other work except distrohopping

If what written in the article from Infoworld about Rust is well put, between the 7 points pro and cons, than the effective implementation along side the rest probably will it would be much more problematic and don't worth.

i really like how he explained "race conditions" so cleanly, in less than 100 pages

Glad I'm not the only one that passionately dislikes this languge! It's indeed time for FreeBSD. Linux has already become too bloated, unstable and has gotten less secure anyways.

But bsd will b fully rewritten with Typescript 🤣🤣🤣

2023 the year of Desktop for BSD.

Rust A.K.A corrosion (🙂) will rot the kernel away from the inside out, lowgrade shitty languages like rust do NOT belong into the kernel because it will not be able to handle the complexity.

Once Flatpak is working ozf freebsd, there would be nothing preventing the use of BSD.

TL;DR
- Rust Is Going To Destroy The Linux Kernel!
- No, It's not.

I really love it when non-devs give technical opinions on something they never do before in their lives.

Can you even write a proper Go program, let alone C and Rust lol.

Just being able to use shells, write config, compile and run programs doesn’t give you any real concrete ideas about how software engineering works let alone the role Rust plays in the kernel lol.

What is your implied “**nuisance**” for having Rust code in the kernel? I really, really want to know. On my Arch desktop I compile my own kernel from AUR, and there is very minimal changes after 6.1 if at all to the way I build these packages. Or are you a kernel packager?

As a young developer myself, I spent most of my college years learning C/C++ for use in low level programming and embedded systems, but Rust has a lot of improvements that make it my new ideal language for those types of use cases. I think it would be a mistake overall to reject Rust as an option for Linux development going forward. I don't think it'll replace C/C++ systemwide. There is a lot of great C/C++ code that doesn't need to be rewritten. Rust though is perfect for managing a lot on the hardware level and less likely to have bugs and security flaws. Younger developers like myself are not going to know C as well as previous generations either. C will become a legacy language eventually so building Linux shouldn't be stuck to that forever or it'll be less likely for development to be continued in the future.

What about... this -- after every memory (leak) related bug found in kernel, the relevant part gets replaced with Rust rewrite of the code. How long will it take to replace the entire kernel?

The only thing that matters to me is that the compiler is able to make reliable, stable and performant machine code out of the source language AND, that developers will continue to contribute.

I think the Linux kernel is, for the lack of a better term, too big to fail. People will ultimately vote with their commits but the idea that the kernel project could splice into a Rust and Anti-Rust variant seems impossible to me. If Rust can be compiled into competitive machine code with C and effectively improve the memory safety, then ham on nerds.

One thing people may not know, is that Google themselves were the ones that spearheaded the inclusion of Rust into Linux, after their own experiments with it in their own products (including Android)

All these woke zoomers and reddit script kiddies who can't be bothered to learn a real languange should not be trusted with kernel development.

It's been a few years since i did real low level programming. Like asm and C(no ++).
It always bugged me that the stuff that i did not want to take care about got angry about the fact that i'm not caring and came back to bite me in the S.
It is maybe an extreme in me, but i think this affects all devs to a certain level. So if rust can shoulder some of that i'm all in.
The point where i am against it is when people become completely oblivious of things like mutex or GC in background and do not account for it anymore and then it leads to issues.
So having made clear that i did not write a single line of impressive code in over a decade (or ever), i feel like if Rust is done right, it might improve in the dev process here and there.
I haven't seen a kernal panic message in 20 years thank to the dilligence of the kernal and driver devs, but i also sometimes wish it wouldn't take eons for certain things to show up in the drivers or the kernel.
Rust might just be what we've been waiting for.

if your code is unsafe or bad, then it wouldn't compile at first place, that's the power of Rust.

A language which is perfectly good for application programming might or might not be good for kernel programming. For example, a language which handles concurrency using Posix mutices won't work in the kernel -- because the kernel cannot depend on the usermode libraries which support Posix. If Rust developers want Rust in the kernel, then choose something in the kernel which is quite important and convert that thing to Rust. Then prove that the code runs just as rapidly and well as its ancestor C version. Iterate. If Rust is capable of writing a kernel, you'll succeed. If it isn't, you will have a target for enhancing Rust.