I would agree for the most part. I consider Rust to be a rather young language. While it is interesting and it should be used to build all sorts of applications, I don’t think it is ready to be implemented into a kernel. Having said that, I also see that the Linux Kernel team is not saying when Rust will be fully implemented despite heavy pressure from the Rust developers and community. We have seen many languages come and go over the years. Some started out brilliantly only to fade over time. I say, Let’s let Rust mature over time and age. Then reconsider in, say five years, the advisability of including Rust in a kernel. Prematurely committing to making Rust part of a kernel carries the potential of unforeseen consequences which may be very costly. Better to wait a bit and see how the language matures.
I agree with you. It may sound strange, but my assumption is that kernel developers have done their due diligence and enough research to make that decision. If they were pressured or made an uneducated decision under false impressions, then the fault is on the kernel devs more than anybody else. On the other hand, if it's up to me, I would have waited until Rust standardization.
@@TheOpenBSDguy yes, the devs are responsible for their decisions and should exercise due diligence. I am not a programmer. Based on what I have read, standards can vary from company to company. It also seems that kernel devs operate with even more restrictive standards than most industries. From my perspective, standards derive, in part, from experience with a given language. So, it makes sense to me for the Linux devs to open the door to some limited Rust development in the kernel in order to gain experience with the language in the kernel environment. Doing so improves the chances of arriving at good standards for Rust development in the kernel.
The question is there was any language more similar to rust in terms of characteristics that just fade away? Personally The way how rust behave on mcus looks very promising
Btw I'm also like you I'm not the type of person that got hyped with anything around to the point where I wasn't using Lua for years just recently for example, cheers from Morocco
Being open to experimentation and the scientific method are how we know what parts of an OS written in a language can be replaced by other methods and languages :)
I can't wait for the Linux kernel to get Rusty! I was skeptical at first until I did the proper research, and bias aside kernels written in Rust (or in this case the Linux kernel modified with Rust) is definitely the future. There's an entire operating system written in Rust called Redox OS, although it's still in development. Go check it out and read through the docs.
Here's my two cents on the matter: - Rust right now is not that "self-hosting" as Theo would like, since it depends on LLVM (that it's written in C++ and C) and Rustc (IIRC) is self-compiling (although the original compiler was written in OCaml, which in turn is written in C). For a standard base the less dependencies you have the better, since you're going to have less code and less bugs. The QBE project seems promising, and I hope it would be able to get the 80/90% of performance of GCC or LLVM with a fraction of the codebase. - The improvement in hardware performance are inhevitable due to Moore, Huang and Amdahl laws, but people seldom remember the Wirth law: "software becomes bigger and slower fadter than the hardware becomes faster". This should make us definitely think about the relation between software and hardware. They're both important, and I think that parts like kernel and base utils should be "tailored" to exploit the potential of the machine, yet maintaining portability. - Nowadays there's a "political war" between Rust community and other language communities, mainly C. I've seen nasty things from the Rust community, like people saying that C is just pure crap or claiming without any evidence that POSIX ABI is broken, blaming some of their problems on other codebases. We could just do without these useless wars. - Is not a case that Rust is gaining momentum, while other languages (like Zig, Hare or Oberon) didn't took on. Look who pours the money at: is not just the users that decide, companies have a much higher impact than the single programmer. And I think it's one of the reasons why Python won over other scripting languages like Lua, TCL and Guile/LISP, despite not being the best we can get (mainly for speed reasons and lack of useful things like tail recursion). If DRM/DRI gets re-written in Rust, it might be forked or a similar (and I hope simpler) framework could be engineered; the challenge is maintaining compatibility with drivers that already exist.
"The QBE project seems promising, and I hope it would be able to get the 80/90% of performance of GCC or LLVM with a fraction of the codebase." - Can you pls explain better - What are youtalking about,what's QBE project ??? Thanks.
i personally don't consider it a big deal for rust to be added into the kernel as long as its used well enough. on switching to openBSD, being on linux already has a few pains when it comes to support (its pretty small for me, but its still there), and this is the case for many linux users, so switching to openBSD and having both pains coming from linux while even linux still having pains on top of that would be too much for most to consider.
@@TheOpenBSDguy generally i havn't any experience about BSD but i want to get rid of bloatly linux kernel. And i think little bit hard but when you search, you can find solutions.
Your opinions are correct, but we're talking about an OS, something that must be incredibly fast and also be low level. People that are using rust are praising it to be fast, safe, better than C++, but it is not. Rust is fast, but not as fast as C code, and while the common saying that developer time is more important, in this field it's different, this is code that will be ran on servers 24/7, which will be executed millions of times, and even 2% slower seems a lot. The safety of the language is a fact... if they're not using it for low level stuff, which is 100% of what they're going to do, so most of the code (look at the github files) are written in the rust's unsafe block, which disables some compilations errors. Being better than C++, I cannot say this, but what I can say is that C++ is 50yo, while rust is 14, this means that there are a lot of performance improvments and bugs that need to be addressed. The idea is not "rust is good" the idea is "rust is better than C++" which is toxic and will not end well. Also another topic that they don't mention is rust code is bloated when compiled which will increase the image size.
I slightly disagree with the speed argument. As I mentioned in the video, I think new hardware makes up for that. It's not ideal, and believe me I am not a fan of it at all but it is true. Nothing irritates me more than loading a webpage that causes the CPU to spike on a-not-so-new hardware. Of course, this is my view as a normie dev, not a kernel dev. On devs writing unsafe code, I agree and no language can stop them from writing stupid code. Telling that Rust fixes that entirely is a mere illusion. That's why we shouldn't put Rust on a pedestal. Those who are hyping up Rust are wrong and doing a disservice to the language. I would dismiss arguments of that nature. Rust is a good language but it has its flaws. It is not bulletproof. In some aspects, it is superior to C/C++, and in some not. It's not a black-and-white thing.
That's why DARPA uses it, and, finance until statements were made against killing humans like a boss. Anyway many systems and relevant organizations choose poor Unix, well written code because they lack money and brain power. Maybe one day they rise enough money to run the current bloated thing, terrible, horrible written but rich a.f. stuff.
I wish you all a happy new year
same dude
Happy New Year
Happy new year 🎉
Happy new year!!!
Have a joyful and prosperous new year. 😀
I would agree for the most part. I consider Rust to be a rather young language. While it is interesting and it should be used to build all sorts of applications, I don’t think it is ready to be implemented into a kernel. Having said that, I also see that the Linux Kernel team is not saying when Rust will be fully implemented despite heavy pressure from the Rust developers and community. We have seen many languages come and go over the years. Some started out brilliantly only to fade over time. I say, Let’s let Rust mature over time and age. Then reconsider in, say five years, the advisability of including Rust in a kernel. Prematurely committing to making Rust part of a kernel carries the potential of unforeseen consequences which may be very costly. Better to wait a bit and see how the language matures.
I agree with you. It may sound strange, but my assumption is that kernel developers have done their due diligence and enough research to make that decision. If they were pressured or made an uneducated decision under false impressions, then the fault is on the kernel devs more than anybody else.
On the other hand, if it's up to me, I would have waited until Rust standardization.
@@TheOpenBSDguy yes, the devs are responsible for their decisions and should exercise due diligence. I am not a programmer. Based on what I have read, standards can vary from company to company. It also seems that kernel devs operate with even more restrictive standards than most industries. From my perspective, standards derive, in part, from experience with a given language. So, it makes sense to me for the Linux devs to open the door to some limited Rust development in the kernel in order to gain experience with the language in the kernel environment. Doing so improves the chances of arriving at good standards for Rust development in the kernel.
The question is there was any language more similar to rust in terms of characteristics that just fade away? Personally The way how rust behave on mcus looks very promising
Btw I'm also like you I'm not the type of person that got hyped with anything around to the point where I wasn't using Lua for years just recently for example,
cheers from Morocco
Being open to experimentation and the scientific method are how we know what parts of an OS written in a language can be replaced by other methods and languages :)
I can't wait for the Linux kernel to get Rusty! I was skeptical at first until I did the proper research, and bias aside kernels written in Rust (or in this case the Linux kernel modified with Rust) is definitely the future. There's an entire operating system written in Rust called Redox OS, although it's still in development. Go check it out and read through the docs.
I'd be curious to know what software you're using to record everything.
,,proudly"🥺
Here's my two cents on the matter:
- Rust right now is not that "self-hosting" as Theo would like, since it depends on LLVM (that it's written in C++ and C) and Rustc (IIRC) is self-compiling (although the original compiler was written in OCaml, which in turn is written in C). For a standard base the less dependencies you have the better, since you're going to have less code and less bugs. The QBE project seems promising, and I hope it would be able to get the 80/90% of performance of GCC or LLVM with a fraction of the codebase.
- The improvement in hardware performance are inhevitable due to Moore, Huang and Amdahl laws, but people seldom remember the Wirth law: "software becomes bigger and slower fadter than the hardware becomes faster". This should make us definitely think about the relation between software and hardware. They're both important, and I think that parts like kernel and base utils should be "tailored" to exploit the potential of the machine, yet maintaining portability.
- Nowadays there's a "political war" between Rust community and other language communities, mainly C. I've seen nasty things from the Rust community, like people saying that C is just pure crap or claiming without any evidence that POSIX ABI is broken, blaming some of their problems on other codebases. We could just do without these useless wars.
- Is not a case that Rust is gaining momentum, while other languages (like Zig, Hare or Oberon) didn't took on. Look who pours the money at: is not just the users that decide, companies have a much higher impact than the single programmer.
And I think it's one of the reasons why Python won over other scripting languages like Lua, TCL and Guile/LISP, despite not being the best we can get (mainly for speed reasons and lack of useful things like tail recursion).
If DRM/DRI gets re-written in Rust, it might be forked or a similar (and I hope simpler) framework could be engineered; the challenge is maintaining compatibility with drivers that already exist.
That's insightful
"The QBE project seems promising, and I hope it would be able to get the 80/90% of performance of GCC or LLVM with a fraction of the codebase."
- Can you pls explain better - What are youtalking about,what's QBE project ???
Thanks.
I would have to agree with you.
i personally don't consider it a big deal for rust to be added into the kernel as long as its used well enough.
on switching to openBSD, being on linux already has a few pains when it comes to support (its pretty small for me, but its still there), and this is the case for many linux users, so switching to openBSD and having both pains coming from linux while even linux still having pains on top of that would be too much for most to consider.
Didnt know android was using it already. Thats a big case of success
How'd you make the slides?
With `mdp` - ua-cam.com/video/Mg7eT2eWyXQ/v-deo.html
rust in linux was one of the many reasons why i ditched it in favor of netbsd.
when was linux get rust i moved to openbsd
Congrats. If you don't mind, can you share the reasoning behind your decision? How is your experience with OpenBSD so far?
@@TheOpenBSDguy generally i havn't any experience about BSD but i want to get rid of bloatly linux kernel. And i think little bit hard but when you search, you can find solutions.
Your opinions are correct, but we're talking about an OS, something that must be incredibly fast and also be low level. People that are using rust are praising it to be fast, safe, better than C++, but it is not. Rust is fast, but not as fast as C code, and while the common saying that developer time is more important, in this field it's different, this is code that will be ran on servers 24/7, which will be executed millions of times, and even 2% slower seems a lot. The safety of the language is a fact... if they're not using it for low level stuff, which is 100% of what they're going to do, so most of the code (look at the github files) are written in the rust's unsafe block, which disables some compilations errors. Being better than C++, I cannot say this, but what I can say is that C++ is 50yo, while rust is 14, this means that there are a lot of performance improvments and bugs that need to be addressed. The idea is not "rust is good" the idea is "rust is better than C++" which is toxic and will not end well. Also another topic that they don't mention is rust code is bloated when compiled which will increase the image size.
I slightly disagree with the speed argument. As I mentioned in the video, I think new hardware makes up for that. It's not ideal, and believe me I am not a fan of it at all but it is true. Nothing irritates me more than loading a webpage that causes the CPU to spike on a-not-so-new hardware. Of course, this is my view as a normie dev, not a kernel dev.
On devs writing unsafe code, I agree and no language can stop them from writing stupid code. Telling that Rust fixes that entirely is a mere illusion. That's why we shouldn't put Rust on a pedestal.
Those who are hyping up Rust are wrong and doing a disservice to the language. I would dismiss arguments of that nature. Rust is a good language but it has its flaws. It is not bulletproof. In some aspects, it is superior to C/C++, and in some not. It's not a black-and-white thing.
completely agree
OpenBSD is poor
That's why DARPA uses it, and, finance until statements were made against killing humans like a boss. Anyway many systems and relevant organizations choose poor Unix, well written code because they lack money and brain power. Maybe one day they rise enough money to run the current bloated thing, terrible, horrible written but rich a.f. stuff.